On Mon, Mar 25, 2013 at 4:25 AM, Vic Devin <vfn...@gmail.com> wrote: > 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. >
I very much doubt that any serialization framework *ever* created a giant leap forward. Sometimes it makes sense to revisit the plumbing and build a better "wheel" because the original design wasn't well suited to how it is currently used (ironically this has, in fact, happened several times with the wheel... nobody uses the original design). In the case of protocol buffers, there were lots of problems with existing frameworks. If you don't perceive any problems, you probably shouldn't bother using protocol buffers. Indeed, your perception of what protocol buffers are suggests a use case where they'd be a bit of a square peg to your round hole anyway. 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! > There is a certain philosophy that goes along that way. More than a few hundred times it has been demonstrated to be problematic, particularly when working on solutions that are unique in some capacity (sometimes just scale or efficiency requirements). Certainly it's not hard to talk to folks who have switched to protobufs from other serialization frameworks and realized significant wins. It's been a big enough deal that other projects have spun up trying to improve on the advantages of protobufs. > Ideally I want to concentrate on the "business logic", relying on the fact > that I dont need to care about the rest. > Ideally, I want hardware constraints & failures not to happen. We don't often get to live in an ideal world. I agree though, it'd be nice if it weren't ever an issue. I don't see how fixing the plumbing so it works better somehow gets in the way of other people living in a world where the plumbing is never an issue... > The standard that defines remote communication is (or used to be!?) CORBA. > Umm... no. Which version fo CORBA would be that "standard" then? Would that be CORBA 1.0 (hard to believe since it didn't even have a standardized serialization format for over the wire communications), Corba 2.0, which generally doesn't support encrypted transport and won't get through most firewalls? Or was that Corba 3, with it's common Component Model? Is that using IIOP (which ironically, doesn't work so well over large portions of the Internet), or HTIOP, or SSLIOP, or ZIOP? Presumably it is an implementation with a POA because without that most stuff doesn't work together at all? CORBA never really took over. It had a brief window of opportunity when Netscape integrated IIOP in to the browser, but that has long since passed. To this day NFS still talks ONC-RPC, and SMB is basically Microsoft's evil DCE RPC variant. I think there are still some ugly DCOM things floating around as well. If you talk to Facebook/Twitter/most other web services, you're mucking around with JSON or XML (over SOAP or REST), and of course there's all that WSDL out there. Heck, even Java programs that used RMI (mostly all dead and buried at this point), where CORBA compatibility was in theory just a configuration flag you set, generally eschewed using RMI-IIOP and instead went with JRMP whenever possible. More importantly though, lots of people don't even using protocol buffers for remote communications, but rather for storing data (arguably this was the primary use case at Google originally as well), and CORBA's solutions in that space were *anything* but broadly used and for most people would be solving the wrong problem (seriously, who would want to store web log data in something like ObjectStore?!). > Using a standard is like talking the same language, so there is a bigger > chance that we might better communicate and understand each other. > Yes, but one problem with a lot of standards (CORBA included) is that in practice they end up representing multiple ways of doing things, making it so that implementing "the standard" is like implementing half a dozen standards (actually, CORBA and ASN.1 both have so much functionality and are flexible enough I'm sure there is a way to make them compatible with a particular use case of protocol buffers with minimal effort), which in practice means that instead of implementing one thing well, you end up implementing several things poorly. CORBA was complicated enough that it actually didn't work terribly well at all until after the hype about it had died down. Honestly, your entire line of reasoning could just as easily have applied to CORBA when it came out (indeed, IIRC CORBA was so much a reinvention of the wheel that HP's original CORBA ORB was implemented on top of their existing RPC solution). I get that you don't see the advantage of using protocol buffers for your circumstance, and given you know the problem better than anyone else in the discussion, odds are you are correct. But please don't try to argue that this makes CORBA a standard or a better solution for everyone's needs than protocol buffers. --Chris > On Thursday, March 21, 2013 7:55:24 PM UTC+2, Feng Xiao wrote: >> >> >> >> >> 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 >>> 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. >>> >> What's the standard that defines remote communication? Who defines the >> standard and why should we follow? >> >> >>> >>> 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. >>> >>> Visit this group at >>> http://groups.google.com/**group/protobuf?hl=en<http://groups.google.com/group/protobuf?hl=en> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> >> -- > 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 this group, send email to protobuf@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. > > > -- Chris -- 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 this group, send email to protobuf@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.
