--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
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.
It is also hard to draw a fair comparison without identifying a particular implementation of ASN.1 to compare against. Most implementations I've seen are rudimentary at best. They might generate some basic code, but they don't offer things like descriptors and reflection.
So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller, faster, more robust, and easier-to-understand ASN.1.
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.
> To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
On Nov 9, 2:59 am, Kenton Varda <ken...@google.com> wrote:You can extend it even without using tags. I used tags to show a more
> OK, I looked into this again (something I do once every few years when
> someone points it out).
>
> ASN.1 *by default* has no extensibility, but you can use tags, as I see you
> have done in your example. This should not be an option. Everything should
> be extensible by default, because people are very bad at predicting whether
> they will need to extend something later.
similar encoding as Protobuf.
> The bigger problem with ASN.1, though, is that it is way over-complicated.You saw on my example that syntax is quite similar to that of
> 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.
>
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.
The encoding can be shorter or bigger, depending on
the enconding rules used. PER is a good example of short encoding, if
length is important in a specific project.
And the best part is that all these encodings are STANDARD. Why to
create a propietary implementation if there is a standard?
It is like microsoft using their propietary formats for offiice
documents, instead on open standards.
Wht if tomorrow Microsoft says : "Oh, I need something simpler than
ASN.1, so we will create a different model": And then we wil have a
different version of "protobuf". And like this, many companies could
develop their own implementations.
> It is also hard to draw a fair comparison without identifying a particularWell, Google, with all their resources, could have, instead of
> implementation of ASN.1 to compare against. Most implementations I've seen
> are rudimentary at best. They might generate some basic code, but they
> don't offer things like descriptors and reflection.
creating "something like ASN.1, but different", put some effort
developing some apis, like those from protobuf, but for ASN.1. They
could have supported maybe a subset of full ASN.1, but they would
still be using an standard, and it would be easier to communicate with
existing systems that support ASN.1
> So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller,Oh, come on, you are not being serious. You can say many of those
> faster, more robust, and easier-to-understand ASN.1.
things. What do you mean, for instance : "faster" ??
ASN.1 has no speed. The speed comes from the ASN.1 compiler.
"More
robust" ?? I see there are, like with any development, bugs that are
being fixed. Better to stick with somethign that has been used for
over 20 years, if you think about "More robust":
"Easier to understand", well, you saw my example, and it is very easy
to understand.
On Nov 9, 10:13 am, multijon <multi...@gmail.com> wrote:Again I must insist about this. ASN.1 doesn't use memory allocations.
> As a side note, the company I worked at used ASN.1 for five years to
> encode all of its product's communication messages (Using PER
> encoding), with what was supposed to be a highly optimized
> implementation of ASN.1.
>
> One of my last projects in the company was to try and convert our
> encoding method (and the underlying data structure) from ASN.1 to
> Protobuf. A project that was estimated to be long and tiring turned
> out to be rather easy, eliminating plenty of unnecessary (in protobuf,
> but necessary in ASN.1) memory allocations, thus both speeding
> performance and decreasing the memory footprint of our product by
> 50-70% (!).
There are some very good, like from OSS Novalka.
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."
Well, Google, with all their resources, could have, instead of
creating "something like ASN.1, but different", put some effort
developing some apis, like those from protobuf, but for ASN.1. They
could have supported maybe a subset of full ASN.1, but they would
still be using an standard, and it would be easier to communicate with
existing systems that support ASN.1
Oh, come on, you are not being serious. You can say many of thosethings. What do you mean, for instance : "faster" ??
ASN.1 has no speed. The speed comes from the ASN.1 compiler.
"More
robust" ?? I see there are, like with any development, bugs that are
being fixed. Better to stick with somethign that has been used for
over 20 years, if you think about "More robust":
"Easier to understand", well, you saw my example, and it is very easy
to understand.
On Tue, Nov 9, 2010 at 6:15 AM, Kalki70 <kalk...@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.You saw on my example that syntax is quite similar to that of
> 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.
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.
> Maybe the ASN.1 compiler that you used used too many memory
> allocations or was not too fast. There are some very good, like from
> OSS Novalka.
I've used both OSS Nokalva's ASN.1 to Java compiler and protobuf in
anger. protobuf is at least as fast, provides a better API (especially
if you want to do any reflection), and is less buggy than OSS's
product. Being able to build protobuf from source makes our build
process a lot simpler, too.
We actually use both in our system - OSS when we must talk ASN.1 in
external protocols, and protobuf for our internal protocols where we
are not implementing to an external specification.
I think that protobuf's simplicity is a large part of why its
implementation is better than the various ASN.1 products out there.
ASN.1 seems to be the Ada of protocol description languages, really..
Oliver
This thread seems to be a bit old but anyway this topic became suddenly important for me since I start to hear the "Protobuf" new magic word.
Now I was a bit surprised to discover that it is actually the same idea as CORBA!
So the question asked at the beginning of this thread „Why to reinvent the wheel?“ is appropriate.
Why Google need to reinvent the wheel if technologies were available?
Now I have my own answer: companies dont trust anyone but themselves, they aspire to be the world domination force, they dont care about existing standards and they replace them with their own!
Next question is: do I want to live in such a world where there is no trust and collaboration between people for the common good? My answer is NO, which seems to go against the current „politically correct“ way of life of having to be a liberal capitalist „competitive“, against the competitors (as if they were your worst enemies)!
I have the feeling that the computer industry could be much more efficient if there were better standards and improving them instead of reinventing the wheel by private companies!
So when company X will finally be dead, it will bring down also the companies which relied on their wheels, unless of course they will be quick to replace them!
I understand that long-lasting standards drag with them old technologies and way of thinking, but why couldn’t they make a new CORBA standard to be the same as Protobuf if this is so good, but still call it CORBA so that everyone knows which wheel you are talking about, and that it doesnt belong to any particular company but goes to the benefit of us all!?!?
Sure also Microsoft will tell you that you dont need to reinvent the wheel, but provided you use their wheel! ;)
http://dotnet.dzone.com/articles/don%E2%80%99t-reinvent-wheel-part-1
So as I see it this is not so much a technological motivation, rather a political / economical one.
--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.For more options, visit https://groups.google.com/groups/opt_out.
This thread seems to be a bit old but anyway this topic became suddenly important for me since I start to hear the "Protobuf" new magic word.
Now I was a bit surprised to discover that it is actually the same idea as CORBA!
What I mean is that they all try to solve, leaving aside all tech details, the same basic problem, i.e. remote communication between software entities.
Thanks for your quick answers.Maybe my point was not so clearly conveyed. What I mean is not to say which technology is better, CORBA, ASN.1, or Protobuf.What I mean is that they all try to solve, leaving aside all tech details, the same basic problem, i.e. remote communication between software entities.We should be referring to this concept in a more standard way, naming it in a standard way.
To make the comparison with the wheel again, we dont call it anything else then "wheel" because the concept is a given and widely and universally understood.Can you imagine the 1st cave men who first invented it, one would make it wooden and call it "Spinner", another make it marble and call it "Stonner" and another "Crasher".The poor cave men still didnt make the process of abstracting the concept to simply "wheel", away from any particular "implementation details".As I see it the progress happens also because of finding these universal abstractions, and Protobuf dont need to say that reinvented the way of making 2 remote module able to communicate with each other, its simply a different (better) implementation of the same (abstract) concept.
On Thursday, March 21, 2013 10:24:30 AM UTC+2, Oliver wrote:On Thu, Mar 21, 2013 at 8:04 AM, Vic Devin <vfn...@gmail.com> wrote:This thread seems to be a bit old but anyway this topic became suddenly important for me since I start to hear the "Protobuf" new magic word.
Now I was a bit surprised to discover that it is actually the same idea as CORBA!
No it's not - protobuf can be used to build a RPC mechanism, but there are many other things that you can use protobuf for that you can't use CORBA for.For example, I've used it to write persistent EDRs to a file in a structured format, and to stream network messages where there's no simple request/response pairing.The analogy with ASN.1 is a better one (and see my previous comments on that)Oliver
--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Oliver,yes, Protobuf can do many more other things than simply remoter communication, but again my point is that these are all "low level" stuff which is again in "the reinventig wheel territory"; if software industry wishes to make a giant leap forward we should start building applications without even thinking about all these low level details, RPC, serialization formats, etc.In fact thanks to "high level" programming languages we are able to forget the complicated modern CPU architectures which we would have to think about if we were stuck with programming in assembler!Ideally I want to concentrate on the "business logic", relying on the fact that I dont need to care about the rest.
Feng,The standard that defines remote communication is (or used to be!?) CORBA. Using a standard is like talking the same language, so there is a bigger chance that we might better communicate and understand each other.
Oliver,yes, Protobuf can do many more other things than simply remoter communication, but again my point is that these are all "low level" stuff which is again in "the reinventig wheel territory"; if software industry wishes to make a giant leap forward we should start building applications without even thinking about all these low level details, RPC, serialization formats, etc.
In fact thanks to "high level" programming languages we are able to forget the complicated modern CPU architectures which we would have to think about if we were stuck with programming in assembler!
Ideally I want to concentrate on the "business logic", relying on the fact that I dont need to care about the rest.
The standard that defines remote communication is (or used to be!?) CORBA.
Using a standard is like talking the same language, so there is a bigger chance that we might better communicate and understand each other.