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 :)
<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:
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.
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.
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.
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 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).
cheers
--
Torsten
