On Sat, Sep 17, 2011 at 3:24 PM, Michael Mol <mike...@gmail.com> wrote: > 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?
Between major releases, pretty stable. And new releases usually add functionality; I haven't used that much dbus, but I don't think the developers had deprecated much. > 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. That's old, obviously. I have dbus 1.4.12, pretty much "post-1.0". gpsd should update its documentation. >> >>> 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. ORBit was the GNOME implementation of ORB; I don't remember what KDE used, but I believe it was also ORB based. > That said, who is They, and who decided that The standard is D-Bus? The desktop developers. They needed an IPC (because, even if you don't agree, sockets/shrmem/pipes is not an IPC), and they settled on dbus, hosted in freedesktop. Almost everybody else then jumped on dbus, because is light, it works, and is an standard. From http://dbus.freedesktop.org: "D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed." >> >>> 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. Technically you are right. But in that case, a file written in /tmp with permissions 777 and file locking can be used as IPC. In practice, sockets/pipes/shrmem is not an IPC, because they lack a standard protocol. > An application may choose to use only layers 2-3 for IPC, or it may > choose to use D-Bus. Yeah, and they can choose to use assembler. Doesn't mean it actually makes sense to use it. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
