1 |
On Sat, Sep 17, 2011 at 2:36 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
2 |
> On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol <mikemol@×××××.com> wrote: |
3 |
>> 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. |
4 |
>> |
5 |
>> Sockets, be they UNIX domain sockets, IPv4 or IPv6. |
6 |
> [snip] |
7 |
>> Shared memory: |
8 |
> [snip] |
9 |
>> Pipes: |
10 |
> [snip] |
11 |
> |
12 |
> Yeah, but then you need to design, implement and debug a protocol |
13 |
> communication: what part of the wire speaks first, what does it says, |
14 |
> what are the valid responses, etc. |
15 |
> |
16 |
> And then, if other component wants to communicate, it has to learn |
17 |
> your little protocol. dbus standardize this. And it uses sockets, |
18 |
> shared memory and pipes as building blocks, I believe, |
19 |
|
20 |
Reasonable points, all, up to the term 'standardize'. How stable is the API? |
21 |
|
22 |
Apart from our discussions of dbus from a few weeks ago, that's most |
23 |
of what I know about it, quoted from the gpsd man page: |
24 |
|
25 |
USE WITH D-BUS |
26 |
On operating systems that support D-BUS, gpsd can be built to broadcast |
27 |
GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0 |
28 |
stage, we will not attempt to document this interface here. Read the gpsd |
29 |
source code to learn more. |
30 |
|
31 |
> |
32 |
>> Not sure what others there are, but those have existed longer than |
33 |
>> I've been alive, and been standard since the early 1990s. |
34 |
> |
35 |
> They are standard in the sense that they are a low level communication |
36 |
> standard API. An IPC is *way* more than that; dbus is an IPC, because |
37 |
> then you have high level "objects" and "methods", no matter the |
38 |
> language of the two sides of the wire communicating, or even if the |
39 |
> objects live in the same computer or not. |
40 |
> |
41 |
> BTW, there *was* an standard that did everything dbus does: ORB, the |
42 |
> Object Request Broker. They tried to use that as IPC years ago, but is |
43 |
> so damn complicated to implement right they decided to better |
44 |
> implement a new standard. The standard is dbus. |
45 |
|
46 |
Interesting. I'd heard of ORB, even tried to play with it a bit, but |
47 |
the documentation I've found is terrible. Like a number of fields I've |
48 |
poked at, if you wan to understand how to do something, you have to do |
49 |
it, making for a tricky. |
50 |
|
51 |
That said, who is They, and who decided that The standard is D-Bus? |
52 |
|
53 |
> |
54 |
>> Progress is |
55 |
>> adding new functionality, not reimplementing existing functionality as |
56 |
>> new APIs on top of the existing functionality. |
57 |
> |
58 |
> I think you are wrong if you believe that dbus is just "existing |
59 |
> functionality as new APIs on top of the existing functionality". dbus |
60 |
> is a complete IPC system. Neither sockets, shared memory nor pipes are |
61 |
> an IPC, because they lack a well defined protocol. You *can* do the |
62 |
> same you do with dbus if you only use sockets/sharedmem/pipes, but |
63 |
> then you need to do it over and over and over again. Is like the |
64 |
> difference between assembler and C: you *can* do the same with both, |
65 |
> but that does not mean that is actually a good idea to only use |
66 |
> assembler. |
67 |
|
68 |
I take (and even accept) your points on D-Bus having more |
69 |
functionality than the three other IPC mechanisms I described. |
70 |
|
71 |
That said, I disagree that D-Bus is an inter-process control |
72 |
mechansim, but sockets, shm and pipes are not. To draw from networking |
73 |
terminology, sockets, shm and pipes could be seen as being on layers 2 |
74 |
and/or 3 of the OSI stack (shm and unix domain sockets being a |
75 |
definite layer 2, IP sockets being layer 3), and D-Bus represents a |
76 |
mixture of layers 3-5. |
77 |
|
78 |
An application may choose to use only layers 2-3 for IPC, or it may |
79 |
choose to use D-Bus. |
80 |
|
81 |
-- |
82 |
:wq |