On 2010-11-09, at 12:01, Christopher Smith <cbsm...@gmail.com> wrote: > On Tue, Nov 9, 2010 at 6:15 AM, Kalki70 <kalki...@gmail.com> wrote: > On Nov 9, 2:59 am, Kenton Varda <ken...@google.com> wrote: > > The bigger problem with ASN.1, though, is that it is way over-complicated. > > It has way too many primitive types. It has options that are not needed. > > The encoding, even though it is binary, is much larger than protocol > > buffers'. The definition syntax looks nothing like modern programming > > languages. And worse of all, it's very hard to find good ASN.1 > > documentation on the web. > > You saw on my example that syntax is quite similar to that of > protobuf. Yes, it CAN be very complicated, but it doesn't need to be. > You can use it in a simpler way. You are not forced to use all > primitive types. > > You are looking at it merely from the perspective of someone wishing to use > ASN.1, not someone implementing it. The problem is the complexity of > implementing ASN.1 in itself brings with it a number of shortcomings.
In a project (LDAP support for Ruby) that I've been involved with for a few hears, we have to deal with ASN.1 BER encoding; a parser/generator can't really choose to do a subset of the encoding. It's a lot more complex to use the BER encoder than if LDAP were based on something that can be self-describing like PB. ASN.1 is over-complex and under-understood pretty much universally. -a -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
