Thanks, I've contributed in the past - TProcessPoolServer in the python lib is my contribution. I'm not that happy with it but it still serves me well.
On Fri, Jul 12, 2013 at 10:31 PM, Jens Geyer <[email protected]> wrote: > Hi Dvir, > > sounds great. > > If you haven't already, please have a look at the (short) guidelines at > http://thrift.apache.org/docs/**HowToContribute<http://thrift.apache.org/docs/HowToContribute> > > > JensG > > > -----Ursprüngliche Nachricht----- From: Dvir Volk > Sent: Friday, July 12, 2013 2:22 PM > To: [email protected] > Subject: Re: AW: The state of Go support in thrift > > > I'll give it a try soon hopefully. > > One other thing I've noticed is that binary encoding and decoding of > network byte ordered values is implemented in a non optimal way, and looks > like it can be replaced with the standard go way of doing it, which might > not have been available at the time the original support had been written. > On Jul 12, 2013 10:03 AM, "Jens Geyer" <[email protected]> wrote: > > Sounds good. The libraries are intended to implement such things in the >> way that is the most idiomatic and efficient for the language in question. >> The general scheme of things in Thrift shall be met, but if a more >> idiomatic TGoRoutineServer differs too much from the traditional threaded >> server hence the name would be misleading, IMHO this is the way to go (pun >> intended). If, however, a goroutine is more or less equivalent to a >> threaded server, except for the fact that it ises goroutines instead of >> threads, we should stock with the Thrift name to make it easier to port >> things across languages. >> ______________________________**__ >> Von: Dvir Volk >> Gesendet: 11.07.2013 21:43 >> An: [email protected] >> Betreff: Re: The state of Go support in thrift >> >> Thanks Jens. >> >> I'm not sure this mailing list is the place - but what do you think of a >> server that takes advantage of Go's concurrency without complicating >> things >> with TFramedTransport and the TNonBlocking pattern? >> >> Just something called, say TConcurrentServer or TGoroutineServer - more or >> less like a go version of TThreadedServer: It spawns a goroutine per >> connection, which is the recommended pattern of handling connection >> concurrency in Go anyway. >> >> It won't take much effort to extend TSimpleServer to support this - in >> fact >> I did a quick & dirty version of it in a couple of minutes today, and it >> worked fine. >> >> I can try and create such a server, that would be the start of something >> people could easily use. >> >> >> >> On Thu, Jul 11, 2013 at 9:56 PM, Jens Geyer <[email protected]> >> wrote: >> >> > Hi Dvir, >> > >> > your summary is fairly accurate. >> > >> > I did not actively monitor github whether Travis (he made the 1.x > >> upgrade >> > patch) is still working at it over there. At least there were no more >> > patches in the last weeks. Go support in Thrift master surely made a >> great >> > step forward, but of course we still would happily appreciate any > >> patches >> > provided to push the Go 1.x support forward to a more mature state. >> > >> > Best regards, >> > JensG >> > >> > >> > >> > -----Ursprüngliche Nachricht----- From: Dvir Volk >> > Sent: Thursday, July 11, 2013 7:52 PM >> > To: [email protected] >> > Subject: The state of Go support in thrift >> > >> > >> > Hi all, >> > >> > I was wondering about the state of the Go library in Thrift. >> > I tried it out today and this is the state of affairs as I understand > >> it: >> > >> > 1. thrift 0.9 supports an old version of go and is not compliant with Go >> > 1.x, both in the library and compiler. >> > >> > 2. thrift master (1.0) has ported both the compiler and the libraries to >> Go >> > 1.x, but the library is lacking - the non blocking server has been >> removed, >> > only simple server is available, there are missing tests, etc. >> > >> > Is anyone working on the Go library currently? Are there any plans to >> > replace TNonBlockingServer with something else? (indeed a non blocking >> > server misses the point of the Go model). >> > >> > >> > Thanks, >> > >> > Dvir >> > >> >> >> >> -- >> Dvir Volk >> Chief Architect, Everything.me >> http://everything.me >> >> > -- Dvir Volk Chief Architect, Everything.me http://everything.me
