Agreed. Consistency between different programming languages is important to me, unless there are good reasons for inconsistencies and they're well documented.
I suggest that we map the inconsistencies in the wiki once we're done discussing them here. That way newbies can be more aware (given they read the wiki) and it'll be much easier to work on the JIRA tickets. Once we know the inconsistencies we need to make the right choice for thrifts default configuration and then it's time to create the detailed JIRA tickets. I'm kind of a newbie myself and I can't give any input on the inconsistencies themselves so these are my 2c. Any thoughts? On Tue, Mar 10, 2009 at 15:23, Bryan Duxbury <[email protected]> wrote: > OK, I think what we need to do then is make some Thrift-wide decisions > about what a library should provide, and then create JIRA tickets for each > of these features, with sub-issues for languages that don't have the right > features. > > Should we just discuss these features in this thread, or is there a better > approach? > > -Bryan > > > On Mar 10, 2009, at 3:01 AM, Franis Sirkovic wrote: > > I see library unification as a big problem. >> I have used C#, Python and Erlang libraries and there are significant >> differences between them. I suppose other libraries are different too. >> For example, Erlang server will disconnect after 10 seconds (hard coded in >> source) and Python server will wait forever. >> You can stop C# and Java server (they have Stop() methods). Keyboard >> interrupt is only way to stop Python server (I didn't find other way). >> Erlang server has stop "method", but you stop only listener. Client >> connections will stay alive forever. >> Also, there is no way to customize C# or Java servers. There are just >> public >> and private members. I think that there should be a way to customize >> classes >> in all languages. For example, I have this problem because I need >> notification when connection is broken. Of course, couple of standard >> methods in Handler interface (new_client(), closed(), ...) can solve this >> problem. Or, maybe better, just one notify() method that will receive all >> notifications (like Erlang handle_info() function). >> >> Best wishes, Franis. >> > >
