On Tue, Aug 26, 2008 at 10:50 AM, Torsten Curdt <[EMAIL PROTECTED]> wrote: > On Aug 26, 2008, at 10:33, David Reiss wrote: > >>> At least if you expect java to be installed on the system it can't be >>> much easier than that ;) >> >> It's been my experience that it is easier to get a stable lexx/yacc/g++ >> working on a Linux system than Java. > > Ahem ...no offense - but sounds like you are a C guy that just hates java :)
I doubt he is given facebook do use java too. But there are those of us(like me) who don't use java at all, just C/C++ and some scripting languages. C/C++ compilers are on every dev platform pretty much, I don't have java on a single one of mine. (i don't hate java i just deal with high performance code/CELL/GPU programming so java would be a no no) > > <snip/> > >> 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. > >> 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. > > What you really want is to pass in the mapping somehow and get back > the attribute name for the sequence id. >> Finally, the codes would be larger and would >> not lend themselves as well to the variable-length encoding used in >> TDenseProtocol. > > 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: I fail to see the big benefit here? using the sequence id's simplfies the implementation which makes it less bug prone across languages. And has been mentioned in the denseprotocol given most people's sequence id's remain very low the cost of a hash based method would be pretty high. Adding it in as a choice to the user just complicates the interfaces and means more code/bugs. > > 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 > >> 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. > >> If we were going to do it, I'd want to do it like Protocol Buffers do, >> which is basically a #include. (We'd have to have better checking for >> things like duplicate field ids.) This could be done by the parser and >> instantly work in all languages. > > Not sure that really makes a big difference in terms of checking. > But either way - something like that would be nice. > If what you want to achieve is doing the inheritance/include for structures and then flatten them surely one could just generate the sequence numbers in a deterministic way from the includes rather than jumping to hashes? >>> Now you focused more on the optional/required and so on. Indeed all >>> correct. But my focus was more on the fact that ab can be derived from >>> a and b. That means that even old struct implicitly have ab. So when >>> you make the switch you either have support this logic in (every) client >>> or you switch over to only rely on ab and can no longer read older >>> structs. >>> >>> See what I mean now? >> >> My understanding is that you want Thrift to generate code for combining >> values? This would basically make it a programming language, and we are >> not going to be doing that. > > 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. What is the problem here? if you want to swap to the alternate method of representing your data you should use a language specific wrapper that will take a and b and pass ab onto your function which processes ab. it doesn't sound like a thrift problem? > >>> Well, if you only use Thrift for serialization and versioning you >>> might not >>> always have a need for the service stub generation. While this isn't >>> really a big problem I am wondering if these aren't two separate things. >> >> 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. What is your point exactly in this regard? i'm not sure how its a problem given it doesn't generate the stubs if you don't need them? Most of the code in the platform libraries is well seperated so one could rebuild lacking the network aspects if one wished.. > > > 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. This has come up time and again recently, and I honistly don't really see where people are coming from all that much. Thrift was designed as a lightweight protocol, and of late people have suggested alot of things which would turn it into a much slower clunky library which would be useless for alot of us. Sure people have suggested making their X suggestion optional given it will slow things down by a huge margin. But given a few revisions, layer of new features on these 'slow' aspects and eventually we'll end up some overly featured slow RPC library like most of those out there. > 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). And given the number of people doing this of late I think its pretty fair to cut them some slack in this regard. There have been lots of suggestions of late, and honistly most of them bad... with the original developers taking time to answer all of them in full rather than shutting them straight off. Maybe abrupt at times but no one on here is a kid who needs to be coddled over their bad idea? Ian.
