ian data is ever encountered for the time
>> being.
>>
>> Yeah an endianness flag would be needed in IPC to let the other side to
>> know the endianness in the wire packets since there is a potential need to
>> tweak in some cases.
>>
>> Regards,
>> Kai
&g
the wire packets since there is a potential need to
> tweak in some cases.
>
> Regards,
> Kai
>
> -Original Message-
> From: Wes McKinney [mailto:w...@cloudera.com]
> Sent: Saturday, April 23, 2016 11:07 PM
> To: dev@arrow.apache.org; Micah Kornfield
> Subject: R
otential need to tweak in
some cases.
Regards,
Kai
-Original Message-
From: Wes McKinney [mailto:w...@cloudera.com]
Sent: Saturday, April 23, 2016 11:07 PM
To: dev@arrow.apache.org; Micah Kornfield
Subject: Re: Byte ordering/Endianness revisited
I don't see a problem adding endiannes
I don't see a problem adding endianness as a flag in the IPC metadata,
and raise exceptions if big-endian data is ever encountered for the
time being. Since big-endian hardware is so exotic nowadays, I don't
think it's unreasonable to expect IBM or other hardware vendors
requiring big-endian suppor
This was discussed on a previous thread
(https://mail-archives.apache.org/mod_mbox/arrow-dev/201604.mbox/%3CCAKa9qDkppFrJQCHsSN7CmkJCzOTAhGPERMd_u2CMZANNQGtNyw%40mail.gmail.com%3E
the relevant snippet is pasted below). But I'd like to reopen this
because it appears Spark supports big endian system
