I think if you wanted correlation of request response... sure you could
build it as an extension on top of 2 oneway channel.
Error handling... that is an issue, it could be managed by some extension
and event handlers as part of the extension.
To me the #1beauty of Thrift is the cross platform interoperability(#2
speed). It is cross platform because it is simple to port.
Speaking as I try to maintain the AS3 port... can you make this an extension
thinggy please?
Aron
On Tue, Mar 2, 2010 at 12:57 AM, Jeff Brown <jeff.br...@gmail.com> wrote:
> I like the full-duplex approach but the fact that the pattern of
> communication is not explicitly captured in the IDL means that client code
> has to be responsible for correlating messages, and synchronization. Using
> oneway messages also makes it more difficult to ensure that errors are
> reported accurately since they won't be propagated through the Thrift stack
> natively.
>
> Jeff.
>
> On Mon, Mar 1, 2010 at 10:28 AM, Aron Sogor <big...@gmail.com> wrote:
>
> > I was wondering. I think you can achieve streaming already without the
> need
> > to bloat a fairly compact stack.
> >
> > Here is the idea:
> >
> > GameServer
> > {
> > oneway sendClientRequest(dosomething)
> > }
> >
> > GameClient
> > {
> > oneway sendClientResponse(didSomthing)
> > }
> >
> > using a simple full duplex connection:
> >
> > client - > server (client[outputstream] -> server[inputstream])
> > server -> client client[input stream] <- server[outputstream])
> >
> > it is async, and works with existing syntax thrift... etc.
> >
>
