On Aug 26, 2008, at 12:15, David Reiss wrote:
Ahem ...no offense - but sounds like you are a C guy that just hates
java :)
I could say just the opposite of you. :)
Totally not :)
While I did quite a bit java the past years my heritage clearly is C.
It's just that I rather only use it when required these days :)
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.
But it put the burden of managing sequence ids on the user. Which
also make the user require to know how Thrift works :)
In fact if you go with the hash codes you only have to tell the user/
developer about the inner workings of Thrift when there is a
clash ...and that will probably affect way less users.
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.
Again ...pass in the mapping and you are much better off. Then the
thrift_dump will do the mapping for you, it's even more readable and
the 343422352 vs 2 argument does not matter anymore :)
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.
Come on! That's a tiny change in the grammar :)
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 totally with you in OOP ...can't say I agree in this case though.
As the model would be flattened we could also just call it an include
mechanism. It's not really inheritance in the OOP way.
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.
OK ...lets assume you have this:
struct Message {
required string version;
required string os;
...
}
Now we decide that we don't both but want to include the OS version
into version string.
struct Message {
required string versionandos;
...
}
Now essentially versionandos = version + os But this bascially
requires to have a different sequence id. So in order for any client
to read an older version it needs to know and execute that rule. The
same is true for the other way around. You could split a versionandos
to get to the value and os. All deterministic rules. The problem I see
- every client needs to be aware of that rule. And your backwards
compatibility goes down the drain ....unless you keep sending both.
Now of course this is more in the semantical area of the message
attributes. Still this is a versioning issue. And since can't be
handle directly through Thrift the question is - how would you handle
it? Would it be useful to have some sort of layer on top?
See what I mean now?
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.
Hm ...I see two different things in Thrift. One being the RPC library
and the other being the actual serialization and versioning. Not sure
how easy it would be to split though.
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. :)
Glad we are :)
Just because I have a different view from you doesn't mean that I am
not
willing to discuss it.
Sorry, I read the mail a little different. Good then :)
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.
Totally agree. You don't want feature bloat. But I guess a fresh view
on things might also help sometimes :)
I have also some experience in this area. Unfortunately not so good
one which is why I am here now ;)
Hoping that Thrift will help to solve them :)
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.
Totally! And appreciated.
cheers
--
Torsten
