1 |
On Sat, Sep 17, 2011 at 3:24 PM, Michael Mol <mikemol@×××××.com> wrote: |
2 |
> On Sat, Sep 17, 2011 at 2:36 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
3 |
>> On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol <mikemol@×××××.com> wrote: |
4 |
>>> 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. |
5 |
>>> |
6 |
>>> Sockets, be they UNIX domain sockets, IPv4 or IPv6. |
7 |
>> [snip] |
8 |
>>> Shared memory: |
9 |
>> [snip] |
10 |
>>> Pipes: |
11 |
>> [snip] |
12 |
>> |
13 |
>> Yeah, but then you need to design, implement and debug a protocol |
14 |
>> communication: what part of the wire speaks first, what does it says, |
15 |
>> what are the valid responses, etc. |
16 |
>> |
17 |
>> And then, if other component wants to communicate, it has to learn |
18 |
>> your little protocol. dbus standardize this. And it uses sockets, |
19 |
>> shared memory and pipes as building blocks, I believe, |
20 |
> |
21 |
> Reasonable points, all, up to the term 'standardize'. How stable is the API? |
22 |
|
23 |
Between major releases, pretty stable. And new releases usually add |
24 |
functionality; I haven't used that much dbus, but I don't think the |
25 |
developers had deprecated much. |
26 |
|
27 |
> Apart from our discussions of dbus from a few weeks ago, that's most |
28 |
> of what I know about it, quoted from the gpsd man page: |
29 |
> |
30 |
> USE WITH D-BUS |
31 |
> On operating systems that support D-BUS, gpsd can be built to broadcast |
32 |
> GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.0 |
33 |
> stage, we will not attempt to document this interface here. Read the gpsd |
34 |
> source code to learn more. |
35 |
|
36 |
That's old, obviously. I have dbus 1.4.12, pretty much "post-1.0". |
37 |
gpsd should update its documentation. |
38 |
|
39 |
>> |
40 |
>>> Not sure what others there are, but those have existed longer than |
41 |
>>> I've been alive, and been standard since the early 1990s. |
42 |
>> |
43 |
>> They are standard in the sense that they are a low level communication |
44 |
>> standard API. An IPC is *way* more than that; dbus is an IPC, because |
45 |
>> then you have high level "objects" and "methods", no matter the |
46 |
>> language of the two sides of the wire communicating, or even if the |
47 |
>> objects live in the same computer or not. |
48 |
>> |
49 |
>> BTW, there *was* an standard that did everything dbus does: ORB, the |
50 |
>> Object Request Broker. They tried to use that as IPC years ago, but is |
51 |
>> so damn complicated to implement right they decided to better |
52 |
>> implement a new standard. The standard is dbus. |
53 |
> |
54 |
> Interesting. I'd heard of ORB, even tried to play with it a bit, but |
55 |
> the documentation I've found is terrible. Like a number of fields I've |
56 |
> poked at, if you wan to understand how to do something, you have to do |
57 |
> it, making for a tricky. |
58 |
|
59 |
ORBit was the GNOME implementation of ORB; I don't remember what KDE |
60 |
used, but I believe it was also ORB based. |
61 |
|
62 |
> That said, who is They, and who decided that The standard is D-Bus? |
63 |
|
64 |
The desktop developers. They needed an IPC (because, even if you don't |
65 |
agree, sockets/shrmem/pipes is not an IPC), and they settled on dbus, |
66 |
hosted in freedesktop. Almost everybody else then jumped on dbus, |
67 |
because is light, it works, and is an standard. From |
68 |
http://dbus.freedesktop.org: |
69 |
|
70 |
"D-Bus is a message bus system, a simple way for applications to talk |
71 |
to one another. In addition to interprocess communication, D-Bus helps |
72 |
coordinate process lifecycle; it makes it simple and reliable to code |
73 |
a "single instance" application or daemon, and to launch applications |
74 |
and daemons on demand when their services are needed." |
75 |
|
76 |
>> |
77 |
>>> Progress is |
78 |
>>> adding new functionality, not reimplementing existing functionality as |
79 |
>>> new APIs on top of the existing functionality. |
80 |
>> |
81 |
>> I think you are wrong if you believe that dbus is just "existing |
82 |
>> functionality as new APIs on top of the existing functionality". dbus |
83 |
>> is a complete IPC system. Neither sockets, shared memory nor pipes are |
84 |
>> an IPC, because they lack a well defined protocol. You *can* do the |
85 |
>> same you do with dbus if you only use sockets/sharedmem/pipes, but |
86 |
>> then you need to do it over and over and over again. Is like the |
87 |
>> difference between assembler and C: you *can* do the same with both, |
88 |
>> but that does not mean that is actually a good idea to only use |
89 |
>> assembler. |
90 |
> |
91 |
> I take (and even accept) your points on D-Bus having more |
92 |
> functionality than the three other IPC mechanisms I described. |
93 |
> |
94 |
> That said, I disagree that D-Bus is an inter-process control |
95 |
> mechansim, but sockets, shm and pipes are not. To draw from networking |
96 |
> terminology, sockets, shm and pipes could be seen as being on layers 2 |
97 |
> and/or 3 of the OSI stack (shm and unix domain sockets being a |
98 |
> definite layer 2, IP sockets being layer 3), and D-Bus represents a |
99 |
> mixture of layers 3-5. |
100 |
|
101 |
Technically you are right. But in that case, a file written in /tmp |
102 |
with permissions 777 and file locking can be used as IPC. |
103 |
|
104 |
In practice, sockets/pipes/shrmem is not an IPC, because they lack a |
105 |
standard protocol. |
106 |
|
107 |
> An application may choose to use only layers 2-3 for IPC, or it may |
108 |
> choose to use D-Bus. |
109 |
|
110 |
Yeah, and they can choose to use assembler. Doesn't mean it actually |
111 |
makes sense to use it. |
112 |
|
113 |
Regards. |
114 |
-- |
115 |
Canek Peláez Valdés |
116 |
Posgrado en Ciencia e Ingeniería de la Computación |
117 |
Universidad Nacional Autónoma de México |