> Ahem ...no offense - but sounds like you are a C guy that just hates > java :) I could say just the opposite of you. :)
>> Regarding hash codes, I think they would complicated the data model > >> and make it more difficult to visually parse binary dumps of >> structures. > > Why? The data model should be the exact same thing. Just that the > sequence id would be 343422352 instead of 2 for example. By "data model", I guess I mean everything that is described in the IDL. Making the field identifiers implicit would mean one extra thing that users would have to learn and remember when dealing with Thrift. Making them explicit makes it easier to understand how Thrift works and takes approximately two seconds for every new field. >> Also, check out the output of thrift_dump in contrib/. That would >> also be less readable. > > Again - how is that supposed to be different? 343422352 vs 2. 2 is much easier to read. > Indeed variable length encoding might not work as good. You would > probably have to store the full integer most of the time. On the > other hand it could left as a choice to the user: > > string something [#1] // sequence number 1 (for those who wants to > maintain it) > > string something // sequence number "something".hashCode (for those > who don't) > string something [somename] // sequence number "somename".hashCode Yeah, this would work. It just increases the complexity of the IDL. >> I think inheritance complicates the data model without adding much >> value. > > Why? What is the problem. For me this would give tremendous value. > If you blend in the the attributes it's merrily (/no) more than an > include. I guess that would be fine. It's just been my experience that composition makes more sends for an IDL. I've only found inheritance useful with virtual functions. > I am talking about a problem here. And I wanted to discuss how to > solve this best. > While support for renaming fields is great, renaming really is only > part of the problem. In that case, I'm still not sure that I fully understand the problem. >> If you don't declare any services, no stubs will be generated. > > That was not my point. This is about the code base and the focus of > the project. The focus of the project is a remote procedure call library. If someone only wants to use one component of it, they are more than welcome. The library code is quite modular. > David, with all due respect. If you guys want grow a community around > this project > you might want to consider becoming a little more open to discussions. I am completely open to discussion. In fact, we are having one right now. :) Just because I have a different view from you doesn't mean that I am not willing to discuss it. > I am not criticizing your baby here. I am trying to understand where > it came from and try > to make suggestions that might make it work better for others (like me). I fully understand. However, please understand my point of view. Many people who are new to this project (myself included!) have tried to add features to it to suit their immediate needs without having a good large- scale view of the project. This has resulted in some fairly limited features that have increased the complexity of Thrift without providing useful improvements, and also features that *have* been useful but have been implemented in individual pieces that could have been combined. Now that Thrift is getting a much bigger audience, I think it is important for someone who has been around for a while to help make sure that all of the newer users don't make the same mistake that I (and others) did. --David
