Not to flog a dead horse TOO much, but while researching some Thrift
related frustrations today, I stumbled across a somewhat old blog entry by
Lev Walkin, developer of the asn1c compiler.
http://lionet.info/asn1c/blog/2010/07/18/thrift-semantics/
I think he does a pretty good job pointing 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!
So the question asked at the beginning of this thread „Why to reinvent
Well, you hit the nail, with that note about M$ Wheel(tm) :D
--
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+unsubscr...@googlegroups.com.
To post to
If you look at the complicated way CORBA works and the simplicity and of
Protobufs, then you know. You assume infinite resources in companies (and
hence assume assume politicial statement behind protobufs), but in reality
it is about getting things done. CORBA is a non-starter.
On 21 March 2013
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
On Thu, Mar 21, 2013 at 8:48 AM, Vic Devin vfn...@gmail.com wrote:
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.
There are plenty of applications of protobuf (and ASN.1 for that matter)
On Thu, Mar 21, 2013 at 1:48 AM, Vic Devin vfn...@gmail.com wrote:
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
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
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
Hello again,
On Nov 9, 2:59 am, Kenton Varda ken...@google.com wrote:
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
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
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.
Unfortunately, you are wrong, it provides forwards
On Nov 9, 10:13 am, multijon multi...@gmail.com wrote:
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
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
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:
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
On Tue, Nov 9, 2010 at 6:21 AM, Kalki70 kalki...@gmail.com wrote:
On Nov 9, 10:13 am, multijon multi...@gmail.com wrote:
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
On Tue, Nov 9, 2010 at 6:44 AM, 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
Yes, this is not a new
On Tue, Nov 9, 2010 at 6:15 AM, Kalki70 kalki...@gmail.com wrote:
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
On Nov 9, 6:15 am, Kalki70 kalki...@gmail.com wrote:
Hello again,
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
19 matches
Mail list logo
