I agree small incremental patches that can be evaluated on their
individual
merits is the best way to go. The beauty of thrift now is it's
simplicity.
I totally agree and I do not want this to change. I wanted to build the
multiple-services client and server and bumped into the fact that th
This is fine, as long as wire-compatibility is not broken.
I agree that the current wire format for single-service implementations
must be kept.
But for multiple-service communication the wire format will be (slightly)
different, so clients written for single-service servers will not be ab
Just joined the mailing list to respond to this thread.
I agree small incremental patches that can be evaluated on their individual
merits is the best way to go. The beauty of thrift now is it's simplicity.
At first glance a multiplexing server looked like a good idea to me. After
thinking abou
One other thing that I forgot to mention is that I would be in favor
of adding a new message type for asynchronous calls, even though
it would changing the wire format and could be kind of a pain to roll
out.
I figured the wire format would not be a problem if the version number is
increased
> I would like for clients and servers to be able to handle requests
> anyway they like. Handling a request consists of the following parts and
> how and when these parts are executed should be flexible:
> - reading the request message header
> - asking the function to read its parameters from the
I disagree with this. The processor provides a simple interface for
selecting a function to call, deserializing its arguments, and
serializing its return value. It implements a part of the protocol,
so replacing can potentially break wire-compatibility. I don't think
that it is a component that
> I do feel however that uniformity across languages is less important.
> [...]
> People working on multiple languages might object though.
I do. :)
>>> - Remove the Client and Processor classes from generated code of
>>> services
>>> so server and client implementations have more freedom concern
Yeah, this is true. That is a more application-visible change, though.
Johan Stuyts wrote:
>> One other thing that I forgot to mention is that I would be in favor
>> of adding a new message type for asynchronous calls, even though
>> it would changing the wire format and could be kind of a pain t
I agree with Bryan that we should break these up into separate JIRA
issues
ASAP. I also think that is important to think of some things in a cross-
language manner. For example, using an options object for constructors
doesn't really require any cross-language consideration, changing the
TProt
One other thing that I forgot to mention is that I would be in favor
of adding a new message type for asynchronous calls, even though
it would changing the wire format and could be kind of a pain to roll
out.
This would give the flexility to the client to decide which functions
should be inv
One other thing that I forgot to mention is that I would be in favor
of adding a new message type for asynchronous calls, even though
it would changing the wire format and could be kind of a pain to roll out.
--David
David Reiss wrote:
> I agree with Bryan that we should break these up into separ
I agree with Bryan that we should break these up into separate JIRA issues
ASAP. I also think that is important to think of some things in a cross-
language manner. For example, using an options object for constructors
doesn't really require any cross-language consideration, changing the
TProtoco
I appreciate the attention to backward compatibility issues, but I don't
think we should be so quick to fork the Java libraries at this stage in
the game. While it may not be possible in every regards to every one of
your suggestions below, I think in general it would be best if we could
ap
This is a very ambitious proposal! I will comment on specifics
inline, but let me start by saying that we should probably create a
lot of separate JIRA tickets for dealing with the ideas raised in
this issue. As one monolithic blob, it will be too difficult to
implement and review.
On Sep
asons.
- Original Message
> From: Johan Stuyts <[EMAIL PROTECTED]>
> To: "thrift-dev@incubator.apache.org"
> Sent: Tuesday, September 9, 2008 2:40:41 PM
> Subject: Redesign of the Java API
>
> Hi,
>
> I thought the move from Facebook to Apache packages might b
Hi,
I thought the move from Facebook to Apache packages might be an
opportunity to redesign the Java API. Redesigning the API at this stage
means that there are no backward compatibility issues: you either use the
old or the new packages. A switch can be added to the compiler to choose
be
16 matches
Mail list logo
