Yes, vote sounds good. List lgtm
On Tue, Apr 2, 2019 at 1:13 PM David Li wrote:
> The proposed changes (also in the document [1]):
>
> Proposal 1: In FlightData, add a bytes field for application-defined
> metadata.
> In DoPut, change the return type to be streaming, and add a bytes
> field to P
The proposed changes (also in the document [1]):
Proposal 1: In FlightData, add a bytes field for application-defined metadata.
In DoPut, change the return type to be streaming, and add a bytes
field to PutResult for application-defined metadata.
Proposal 2: In client/server APIs, add a call opti
I think we can have a vote. Can you write a summary bulleted list of
the changes/additions in brief?
Jacques, what do you think?
On Tue, Apr 2, 2019 at 1:31 PM David Li wrote:
>
> Just wanted to circle back to this - I've gotten a lot of feedback on
> the linked document, and I appreciate all th
Just wanted to circle back to this - I've gotten a lot of feedback on
the linked document, and I appreciate all the suggestions. Discussion
seems to have quieted down; is this ready for a vote (perhaps as
individual format changes)?
Thanks,
David
On 3/22/19, David Li wrote:
> Sorry about that! I
Sorry about that! It should be enabled now, let me know if it doesn't work.
Best,
David
On 3/22/19, Antoine Pitrou wrote:
>
> I second this request.
>
> Regards
>
> Antoine.
>
>
> On Fri, 22 Mar 2019 15:26:26 -0700
> Jacques Nadeau wrote:
>> Hey David, thanks for sharing this. Can you add comme
I second this request.
Regards
Antoine.
On Fri, 22 Mar 2019 15:26:26 -0700
Jacques Nadeau wrote:
> Hey David, thanks for sharing this. Can you add comment capability to the
> doc for reviewers?
>
> thanks,
> Jacques
>
>
> On Fri, Mar 22, 2019 at 1:29 PM David Li wrote:
>
> > Hi all,
> >
Hey David, thanks for sharing this. Can you add comment capability to the
doc for reviewers?
thanks,
Jacques
On Fri, Mar 22, 2019 at 1:29 PM David Li wrote:
> Hi all,
>
> To bring this back up again, we've started experimenting with Flight
> for real now, and have some proposals. Including the
Hi all,
To bring this back up again, we've started experimenting with Flight
for real now, and have some proposals. Including the justifications,
they're a little long, so I've put them on a linked Google doc:
https://docs.google.com/document/d/1aIVZ8SD5dMZXHTCeEY9PoNAwyuUgG-UEjmd3zfs1PYM/edit?usp
On Tue, Feb 12, 2019 at 2:44 PM David Ming Li wrote:
>
> Hi all,
>
>
>
> We've been evaluating Flight for our use, and we're wondering if the protocol
> is still open to extensions, as having a few application-defined metadata
> fields would help our use cases a lot.
>
>
>
> (Apologies if this i
Hey David, I'm +1 for the protocol changes. I think they make sense.
Solving the busy wait in java also makes sense.
On Thu, Feb 14, 2019 at 11:45 AM David Ming Li
wrote:
> Back to extending the protocol, all we should need, and the simple thing
> (IMO) to do, would be:
>
> - Add a `bytes data
Perhaps authentication can wait until we have proper requirements?
There are many authentication schemes around.
Regards
Antoine.
Le 14/02/2019 à 20:44, David Ming Li a écrit :
> Back to extending the protocol, all we should need, and the simple thing
> (IMO) to do, would be:
>
> - Add a `b
Back to extending the protocol, all we should need, and the simple thing (IMO)
to do, would be:
- Add a `bytes data_application = 3` to FlightData
(https://github.com/apache/arrow/blob/master/format/Flight.proto#L286)
- Add a `bytes data_application = 1` to PutResult
- Change `DoPut` to `rpc DoP
For the record, if I run something like
"flight-benchmark -num_streams 32 -records_per_batch 65536
-num_threads 1"
then:
- 80% of the perf-server's CPU time seems spent inside the
implicit memcpy() calls in
SerializationTraits::Serialize() (going through
CodedOutputStream::WriteRaw)
- 8
On Tue, Feb 12, 2019 at 3:46 PM Antoine Pitrou wrote:
>
>
> Le 12/02/2019 à 22:34, Wes McKinney a écrit :
> > On Tue, Feb 12, 2019 at 2:48 PM Antoine Pitrou wrote:
> >>
> >>
> >> Hi David,
> >>
> >> I think allowing to send application-specific ancillary data in addition
> >> to Arrow data makes
Le 12/02/2019 à 22:34, Wes McKinney a écrit :
> On Tue, Feb 12, 2019 at 2:48 PM Antoine Pitrou wrote:
>>
>>
>> Hi David,
>>
>> I think allowing to send application-specific ancillary data in addition
>> to Arrow data makes sense.
>>
>> (I'm also wondering whether the choice of gRPC is appropriat
Even if zeromq did make more sense, we couldn't take it on as a
dependency because of non-ASF-compatible licenses
Java zeromq: MPL 2.0
libzmq: GPL
On Tue, Feb 12, 2019 at 3:33 PM Jonathan Chiang wrote:
>
> Would zeromq make more sense than gRPC?
>
> Thanks,
> Jonathan
>
> > On Feb 12, 2019, at 1
On Tue, Feb 12, 2019 at 2:48 PM Antoine Pitrou wrote:
>
>
> Hi David,
>
> I think allowing to send application-specific ancillary data in addition
> to Arrow data makes sense.
>
> (I'm also wondering whether the choice of gRPC is appropriate at all -
> the current C++ hacks around "zero-copy" are
Would zeromq make more sense than gRPC?
Thanks,
Jonathan
> On Feb 12, 2019, at 12:48 PM, Antoine Pitrou wrote:
>
>
> Hi David,
>
> I think allowing to send application-specific ancillary data in addition
> to Arrow data makes sense.
>
> (I'm also wondering whether the choice of gRPC is app
Hi David,
I think allowing to send application-specific ancillary data in addition
to Arrow data makes sense.
(I'm also wondering whether the choice of gRPC is appropriate at all -
the current C++ hacks around "zero-copy" are not pretty and they may not
translate to other languages either)
Reg
19 matches
Mail list logo
