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
TProtocol interface requires some because it is best to keep uniformity,
and changing the message protocol requires a lot because it is necessary
to keep interoperability.
Okay, as soon as there is consensus that an issue is worth addressing I
will create a JIRA issue for it.
I agree that message protocol changes should only be considered if it
provides enough benefit.
I do feel however that uniformity across languages is less important. If
maintainers of a language are willing to do a bit of extra work to map
from the protocol interface of other languages to their language, I
wouldn't mind having a different protocol interface in that language.
People working on multiple languages might object though.
- A different set of functions for TProtocol so protocol implementations
have more flexibility (For example see
https://issues.apache.org/jira/browse/THRIFT-110 (Changes to the IDL
would
still be required to be able to implement a compact format)).
I think this has to be considered in a cross-language way. The fact that
TProtocol has the same interface in each language means that it is much
easier to code up the same protocol in each language.
I agree that it is easier if the protocol interfaces are the same across
all languages, but the new interface won't make it difficult to keep
languages in sync: instead of writing a field with two methods you write a
field with one method.
Sure it is possible to do the same thing with a stateful protocol, but a
stateful protocol is much more complex than a stateless one. Note that if
you want to verify that the data is always correct the protocol must be
stateful, because you would have to check that a stop field is not
followed by other fields in a structure for example. Neither the current
protocol interface nor the proposed protocol interface will allow this to
be done in a stateless manner.
- Removal of the name when writing the beginning of the structure as
nobody seems to need this
(https://issues.apache.org/jira/browse/THRIFT-8). There is no need to
hang
on to obsolete constructs and confuse new users.
This is currently used in the TDebugProtocol in C++ (which produces
human-readable representations of Thrift structs) and the
TSimpleJSONProtocol
in Java which is a lossy write-only protocol that produces
easily-consumable
JSON strings for scripting languages.
Okay, I'll document that the name of the structure that is passed to the
protocol is meant for human consumption only, and will close THRIFT-8.
- Remove the Client and Processor classes from generated code of
services
so server and client implementations have more freedom concerning how
(service and) function selection information is communicated and
processed, and how I/O is handled. See below.
I don't think that these need to be removed. They are the most common
use
case by far, but it is completely possible to replace them.
It just does not feel right to me where this code is located now. The
processing can differ significantly between implementations. Providing one
method of request processing in the generated code is confusing. Client
and server implementors might hesitate to ignore the code and write their
own request processing, because they feel that would be like working
against the framework.
Also if improvements to the request handling have to be made, all
generated code has to be regenerated. If the code is moved to the client
and server implementations only the library needs to be upgraded and all
deployed code benefits.
To be able to replace Client and Processor other interfaces and classes
are needed (i.e. the Service and Function types I described earlier).
Again I feel it would be confusing if the generated code contained both
Client and Processor, and Service and Functions.
- Add an interface to the generated code and add support classes for
doing
asynchronous calls (i.e. support for sequence IDs). See below.
This can be done without changing any of the existing interfaces.
From the perspective of a caller of a function it does not look this way.
How do I sent a request for which I either:
- poll for the result, or
- get notified by an event.
Each client implementation has to provide its own mechanism now. It would
be nice if Thrift provided standard interfaces (for polling, notifications
or both) for handling asynchronous calls.
- Drop the 'T' prefix of types as this is not customary in Java.
As I said when this was suggested for Ruby, I think that the T
prefix makes it easier to import classes without name collisions and
distinguishes specific interfaces like TProtocol from generic names
like "Protocol" or "Binary".
I think that (except for the case Bryan mentioned) collisions will be very
rare.
This is something that we discussed a few months ago when we had a
meeting
about creating a more compact protocol. It think the generic term we
used
to describe it was "out of bad exchange of IDL information". I think it
is a great idea, but it has to be implemented cross-language.
Interoperability is my main objective. I will not implement another
protocol without consulting other people.
This is not the case. For example, the TNonblockingServer in C++
accesses
sockets directly (via libevent) and hands TMemoryBuffers to the
Processor.
The purpose of the TServerTransport is to make it easier to implement
servers that are less I/O-aware (like the TThreadPoolServer) in a uniform
fashion.
I probably was too bold in my first statement. I think it is desirable to
keep the transports to reuse common methods of communication, but feel
that the transport handling should be pushed more to the background, i.e.
an implementation detail instead of a core abstraction.
The extra layer of transports around I/O streams seems redundant to me.
I would be open to dropping the Transport interface in favor of something
built into Java, but I am not able to find anything that supports both
input and output. For example, it looks like java.net.Socket extends
Object and implements no interfaces.
What about using 'InputStream' and 'OutputStream'? A protocol can be given
the streams which it will read from and write to directly.
I think it is even possible to split protocol into two interfaces:
InputProtocol and OutputProtcol.
--
Kind regards,
Johan Stuyts
