Hi Greg,
So to make sure that I understand you correctly, if I generate a C#
implementation using a Thrift IDL, and communicate with my embedded
firmware product using Thrift's JSON protocol and HTTP transport and on
the embedded side there is no Thrift, there will still be compatibility?
With regard to struct member names and function argument names, yes. Ben
just reminded me that I missed one thing in my previous mail: The function
names are transferred as literal strings, but this is really the only place
where strings are used at all to identify anything from the IDL within
Thrift-serialized data.
Out of curiosity: What do you use to de/serialize the data in the embedded
part?
To make things clearer, here are some examples. The first one is an SO
answer from me which contains an annotated screenshot. It shows the anatomy
of a certain serialized struct, using the binary protocol.
http://stackoverflow.com/a/26517050/499466
If we use JSON, the serialized result looks of course totally different, but
the data contained are essentially the same. This SO answer shows a
complete, JSON-serialized RPC request (note the function name):
http://stackoverflow.com/a/20272860/499466
The third example shows a different data structure serialized using the
Thrift JSON protocol:
{"1":{"str":"Streamtest"},"4":{"i8":-128},"9":{"i32":4711},"11":{"i64":1311768467463790320}}
which is serialized from this Xtruct structure:
private static function MakeTestData() : Xtruct {
var data : Xtruct = new Xtruct();
data.string_thing = "Streamtest";
data.byte_thing = -128;
data.i32_thing = 4711;
data.i64_thing = Int64.make(0x12345678,0x9ABCDEF0);
return data;
}
based on this IDL
struct Xtruct {
1: string string_thing,
4: byte byte_thing,
9: i32 i32_thing,
11: i64 i64_thing
}
You see, that each entry follows the pattern field ID ("1"), type ("str")
and data ("Streamtest"). The type identifiers like "str" and "i8" are fix
and hardcoded into the JSON protocol implementations.
But it does bring up a bigger point, which is that there are preferences
that users might want to realize in the generation. Pipeline programming
in D is one example. I suppose that in this case, though, forking and
customizing is the way to go.
I just had a quick look, and it looks as if that particular task could be
solved by means of an specialized Transport, but seems to be nothing that
affects the generator. But as I said: I had a very quick look only, so maybe
I overlook something important.
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: [email protected]
Sent: Tuesday, December 30, 2014 8:45 PM
To: [email protected]
Subject: Re: Camel Casing in C#
Hi Jens,
If you talk about communicating via Thrift-serialized structures, this is
actually not the case. Thrift identifies struct properties and arguments
not
via name, but via 32 bit numbers, a.k.a field IDs. This makes the whole
thing independent from any actual language representation. Even if an
(hypothetical) language would allow for uppercase letters only, it would
still be possible to exchange data with another language that allows for
lowercase letters or say, egyptian hieroglyphes, only. The mapping in the
wire format is entirely done via the field ID.
So to make sure that I understand you correctly, if I generate a C#
implementation using a Thrift IDL, and communicate with my embedded
firmware product using Thrift's JSON protocol and HTTP transport and on
the embedded side there is no Thrift, there will still be compatibility?
Fun aside: You cannot seriously expect any OSS or commercial project to
adhere to your (basically arbitrary) corporate standards. There are
thousands of companies out there, with probably millions of permutations
of
such standards. Currently, with Thrift all languages' code generators
implement their own, hard-coded way how IDL properties are translated
into
code. There is no template system or the like (this would make some
things
easier).
I agree that this is too much to ask of a tool like Thrift to adhere to
without some templating feature, which is why I caveated my statement. :)
But it does bring up a bigger point, which is that there are preferences
that users might want to realize in the generation. Pipeline programming
in D is one example. I suppose that in this case, though, forking and
customizing is the way to go.
I think that if we can ensure that we have compatibility between the code
generated by the Thrift compiler and our existing firmware code, then
we'll just stay with the generated code. Otherwise, we will need to
implement some type of post-parser that enforces our basic code
requirements.
Thanks,
Greg
-------------------------
From: "Jens Geyer" <[email protected]>
To: <[email protected]>
Date: 12/30/2014 01:54 PM
Subject: Re: Camel Casing in C#
Hi Greg,
[...]
our embedded firmware products [...] written in C
[...]
The data types in the firmware use lower case,
underscored field names, so when we generate
the C# classes, there is inherent incompatibility
between the firmware and software.
If you talk about communicating via Thrift-serialized structures, this is
actually not the case. Thrift identifies struct properties and arguments
not
via name, but via 32 bit numbers, a.k.a field IDs. This makes the whole
thing independent from any actual language representation. Even if an
(hypothetical) language would allow for uppercase letters only, it would
still be possible to exchange data with another language that allows for
lowercase letters or say, egyptian hieroglyphes, only. The mapping in the
wire format is entirely done via the field ID.
and we're exchanging more complex
types rather than simple native types
Doesn't matter. As long as you express it in Thrift IDL the above
statement
holds.
how do we customize the generated code
to meet our corporate standards
Oh, that's easy: Change your corporate standards :-)
Fun aside: You cannot seriously expect any OSS or commercial project to
adhere to your (basically arbitrary) corporate standards. There are
thousands of companies out there, with probably millions of permutations
of
such standards. Currently, with Thrift all languages' code generators
implement their own, hard-coded way how IDL properties are translated into
code. There is no template system or the like (this would make some things
easier).
My thought was to start with command line switches
for the generator, like the ones that are used when
generating Java source.
Was my first thought as well, but I don't think it is a good idea anymore.
Just try to answer the question: How would you name and describe the new
switch?
-gen csharp:corpXYZ Generate code that adheres to the arbitarily
chosen style guide of company XYZ
The only option which (IMHO) really would add value to Thrift would be
either something like a (probably complex) template feature, or a much
simpler version which uses some kind of pre-defined rules that can be
easily
put into a text file:
-gen csharp:style=<file> Generate code that adheres to the coding
rule set given in <file>
But even that involves some work, that's for sure.
Back on main topic: What options do we have if you still need it?
- There are some extensions, mostly in the C++ area, which employ
annotations to get specific behaviours. Could be another way.
- Accept the fact that Thrift does not meet the corporate standards, use
the
arguments above and convince the management.
- Private fork to implement the changes you need. I'm not a big fan of it
(personal opinion), but it is still a valid solution.
What do you think?
Have fun,
JensG
PS: Interesting topic, anyway.
-----Ursprüngliche Nachricht-----
From: [email protected]
Sent: Tuesday, December 30, 2014 3:55 PM
To: [email protected]
Subject: Re: AW: Camel Casing in C#
It's a bit of a problem. One of our use cases is that we have an existing
service contract with one of our embedded firmware products that is
written in C. We'd like to use the Thrift IDL to specify the structures
and services themselves. The data types in the firmware use lower case,
underscored field names, so when we generate the C# classes, there is
inherent incompatibility between the firmware and software.
Admittedly, this is an abbreviation of the purpose of Thrift in that we
are not using RPC to transfer values, and we're exchanging more complex
types rather than simple native types. But the issue with casing uncovers
a related question: how do we customize the generated code to meet our
corporate standards. Is hacking the Thrift generator source code the only
way? Maybe some sort of simple class template file could do the trick. My
thought was to start with command line switches for the generator, like
the ones that are used when generating Java source.
Thanks,
Greg
From: Jens Geyer <[email protected]>
To: "[email protected]" <[email protected]>
Date: 12/30/2014 03:35 AM
Subject: AW: Camel Casing in C#
Hi Gregor,
no, unfortunately not. All available switches are listed on the thrift
--help screen.
Is that a problem with your use case?
Have fun,
JensG
________________________________
Von: [email protected]
Gesendet: 30.12.2014 00:52
An: [email protected]
Betreff: Camel Casing in C#
Can anyone tell me if it is possible to turn on and off camel casing on
property names when generating C#? Basically, if I have a field called
"general" in my .thrift file, I want a property called, "general" in my C#
file. Instead, I get a property called "General".
Thanks,
Greg Lusk
