On Mon, Mar 25, 2013 at 11:25 AM, Vic Devin <vfn...@gmail.com> wrote:
> 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.
Not quite sure where you're trying to go with this discussion, but anyway ..
My point is that you'd picked the wrong abstraction to start with. If it's
not simple to pick the right abstraction in the first place, why do you
think that the standard you end up with is actually going to be universally
useful? Same argument applies even at the lower level. Just picking
something at random, you wouldn't want to use protobuf's encoding in places
where DER is currently used (e.g. digital signatures) because protobuf does
not guarantee a particular encoding for a given input.
Just trying to ignore the low level concerns usually ends up producing bad
software in my experience - yes you can always slap another layer of
abstraction on top of something, but there's a cost to that.
> 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.
Sun RPC, ROSE (and the related uses of it in e.g. TCAP etc.), SOAP, and
plain RMI spring to mind just off the top of my head. What's special about
Having a variety of standards and implementations is actually a good thing
here because they have different characteristics and you can pick the one
that is appropriate for your situation, rather than being forced to live
with the design decisions that someone else happened to make. Have a large
toolkit, pick the right tool for the job, and let the best implementation
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 post to this group, send email to email@example.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.