|Subject||Re: Data Streaming -- New Message Format|
> I hadn't because I didn't know about it. I've had a quick look. ItCan be... though I wonder if people have other opinion.
> looks way too heavy for our purpose.
> In specific, it's schema based and ascii encoded.What do you mean by "ascii encoded" (do you refer to encoding rules in
> It looks reasonable for canonical,From what I've read, it is used in many (if not most of) telco
> inter-organizational message exchange but less appropriate for ad
> hoc communication between database client and server.
equipment/protocols. Personally I like the way the stuff is defined
and a possibility to use different encoding rules for it. I suspect
that we can also plug-in the idea of supporting multiple protocols and
automatic capability negotiation into it.
> Do you have any experience with it?Only experimenting. We have planned to switch to ASN.1 in my previous
company as a language to specify wire protocol between PDAs and
server. But I have changed my job and I have no idea what's the state
of affairs there. The tool I have tested (quite expensive one, if I'm
not mistaken, $4,500 per license) generated quite simple code both in
C++ and Java (do not know anything about C#).
The generated code is going to be bigger compared to our current wire
protocol handler, but the good thing is that you do not need to edit
it - it's like with parse.y. However, it will add dependency on some
external library, I have forgotten about this issue when posting first
message. So, most likely you're right, it might be too heavyweight for us.
BTW, there is already a free implementation of ASN.1 parser
http://lionet.info/asn1c/, though only with Basic Encoding Rules (in
other words type-length-value), but Packed Encoding Rules support is
planned. Though no Java implementation, but other tools are there.
But if nobody has practical experience in ASN.1, I think we have to
forget about it anyway.