On Sat, Sep 17, 2011 at 2:36 PM, Canek Peláez Valdés <can...@gmail.com> wrote:
> On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol <mike...@gmail.com> wrote:
>> On Sat, Sep 17, 2011 at 10:50 AM, Canek Peláez Valdés >>> I would like for
>> you to be more specific about them.
>>
>> Sockets, be they UNIX domain sockets, IPv4 or IPv6.
> [snip]
>> Shared memory:
> [snip]
>> Pipes:
> [snip]
>
> Yeah, but then you need to design, implement and debug a protocol
> communication: what part of the wire speaks first, what does it says,
> what are the valid responses, etc.
>
> And then, if other component wants to communicate, it has to learn
> your little protocol. dbus standardize this. And it uses sockets,
> shared memory and pipes as building blocks, I believe,
Reasonable points, all, up to the term 'standardize'. How stable is the API?
Apart from our discussions of dbus from a few weeks ago, that's most
of what I know about it, quoted from the gpsd man page:
USE WITH D-BUS
On operating systems that support D-BUS, gpsd can be built to broadcast
GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0
stage, we will not attempt to document this interface here. Read the gpsd
source code to learn more.
>
>> Not sure what others there are, but those have existed longer than
>> I've been alive, and been standard since the early 1990s.
>
> They are standard in the sense that they are a low level communication
> standard API. An IPC is *way* more than that; dbus is an IPC, because
> then you have high level "objects" and "methods", no matter the
> language of the two sides of the wire communicating, or even if the
> objects live in the same computer or not.
>
> BTW, there *was* an standard that did everything dbus does: ORB, the
> Object Request Broker. They tried to use that as IPC years ago, but is
> so damn complicated to implement right they decided to better
> implement a new standard. The standard is dbus.
Interesting. I'd heard of ORB, even tried to play with it a bit, but
the documentation I've found is terrible. Like a number of fields I've
poked at, if you wan to understand how to do something, you have to do
it, making for a tricky.
That said, who is They, and who decided that The standard is D-Bus?
>
>> Progress is
>> adding new functionality, not reimplementing existing functionality as
>> new APIs on top of the existing functionality.
>
> I think you are wrong if you believe that dbus is just "existing
> functionality as new APIs on top of the existing functionality". dbus
> is a complete IPC system. Neither sockets, shared memory nor pipes are
> an IPC, because they lack a well defined protocol. You *can* do the
> same you do with dbus if you only use sockets/sharedmem/pipes, but
> then you need to do it over and over and over again. Is like the
> difference between assembler and C: you *can* do the same with both,
> but that does not mean that is actually a good idea to only use
> assembler.
I take (and even accept) your points on D-Bus having more
functionality than the three other IPC mechanisms I described.
That said, I disagree that D-Bus is an inter-process control
mechansim, but sockets, shm and pipes are not. To draw from networking
terminology, sockets, shm and pipes could be seen as being on layers 2
and/or 3 of the OSI stack (shm and unix domain sockets being a
definite layer 2, IP sockets being layer 3), and D-Bus represents a
mixture of layers 3-5.
An application may choose to use only layers 2-3 for IPC, or it may
choose to use D-Bus.
--
:wq
