There are some standards that pack many different ways to put things
under one umbrella. This is because they have been decided by
committee with many different companies involved that all want to
bring in 'their way'. The multitude of ways to encode things with
ASN.1 (why there is more than one ?) or to choose between encoding
with tags or without (from what I gathered from this communication)
means that there are more ways than one to do things.

How worth is a standard of communication if there are a myriad ways to
do things ? You end up with implementations that only support part of
it and suddenly the standard becomes worthless because two different
implementations don't support the same options of doing things on both
sides.

This discussion reminds me of SOAP. In the beginning, there was
XML-RPC - extremely simple way to communicate using XML with some
small shortcomings but a developer could get started in seconds
reading a simple example communication.
Then standard committees came in and started developed SOAP: out came
a 'standard' that easily is printed 5000 pages with all different ways
to encode things in XML, different transport schemes etc. Same problem
for many years: many implementations that all couldn't speak to each
other. Complicated to use (Yes and I wrote a book about it - I'll
never touch SOAP again).
It got a bit better but people moved on and don't use SOAP anymore.

Protocol buffers are simple and there is only one way to do things.
Simplicity usually wins over developers. This is why they developed
Protocol Buffers at Google in the early 2000s. They're putting it out
here for others to use, but you don't have to.

On Tue, Nov 9, 2010 at 06:44, Kalki70 <kalki...@gmail.com> wrote:
> Oh, I just found out that you are the developer. It seems I am not the
> only one who thinks you reinvented the wheel :
>
> http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html
>
> As someone mentioned there :
>
> "The apparent complexity of ASN.1 is largely due to its flexibility -
> if you're using only the sort of functionality that pbuffer gives you,
> it would be pretty much the same, I would think."
>
> Luis.
>
> On Nov 9, 2:42 am, Kenton Varda <ken...@google.com> wrote:
>> My understanding of ASN.1 is that it has no affordance for forwards- and
>> backwards-compatibility, which is critical in distributed systems where the
>> components are constantly changing.
>>
>> On Mon, Nov 8, 2010 at 7:34 PM, Kalki70 <kalki...@gmail.com> wrote:
>> > Hello,
>>
>> > I just discovered this developers tool, and I can't understand why it
>> > was invented. Why didn't Google use ASN.1, which is standard and it is
>> > used for this, to make a language, platform independent description of
>> > data to be enconded later as XML, or different binary formats, that
>> > can be faster and more efficient?
>>
>> > All this is like reinventing ASN.1
>>
>> > For instance, the example shown on the web page :
>>
>> > message Person {
>> >  required string name = 1;
>> >  required int32 id = 2;
>> >  optional string email = 3;
>>
>> >  enum PhoneType {
>> >    MOBILE = 0;
>> >    HOME = 1;
>> >    WORK = 2;
>> >  }
>>
>> >  message PhoneNumber {
>> >    required string number = 1;
>> >    optional PhoneType type = 2 [default = HOME];
>> >  }
>>
>> > In ASN.1, which is a standard used for over 20years, the same could be
>> > written similar to this (I haven't used it in a while, maybe I made
>> > some mistakes ):
>>
>> > PhoneType ::= ENUMERATED { MOBILE, HOME, WORK }
>> > PhoneNumber ::= SEQUENCE
>> > {
>> >    number [1] IA5String ,
>> >    phone [2] PhoneType DEFAULT HOME
>> > }
>>
>> > Person ::= SEQUENCE
>> > {
>> > name   [1] IA5String ,
>> > id          [2] INTEGER,
>> > email   [3] OCTET STRING OPTIONAL
>> > phone [4] SET OF PhoneNumber
>> > }
>>
>> > Best regards,
>>
>> > Luis
>>
>> > --
>> > 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<protobuf%2bunsubscr...@googlegroups.com>
>> > .
>> > For more options, visit this group at
>> >http://groups.google.com/group/protobuf?hl=en.
>
> --
> 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.
>
>

-- 
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.

Reply via email to