Linked by Dennis Heuer on Mon 28th Nov 2005 16:31 UTC
General Development The ICT-Business is known for strategic terms. One of those terms, which was used quite a lot over this year, is services. The term is interpretable; however, the focus was on technical concepts implemented to serve for a sharply rendered use case, like managing user data and authentication. Services in that sense are served over a type of network. Despite the first impression, they are not served to a user but to a calling application. This client utilizes one or more services for internal purposes. Though, the user may be expected to provide data (the password, for example) or to wait and receive a gathered result.
Order by: Score:
He?
by miro on Mon 28th Nov 2005 17:09 UTC
miro
Member since:
2005-07-13

1) No idea how Eclipse is related to DBUS
2) Wouldn't it be easier if both xine and totem would register with a well known org.gnome.mixer service?

On the otherhand, some kind of store could be needed, both DCOM (registry), CORBA and Internet(DNS) have one (for good reasons).

There could be service org.freedesktop.dns, with a known interface that could answer questions like: "give me all printer spoolers", etc.

So let's talk:)

Reply Score: 2

Errrrrrr
by segedunum on Mon 28th Nov 2005 17:16 UTC
segedunum
Member since:
2005-07-06

Who said D-BUS was going to provide a services network?

Reply Score: 2

COM replacement?
by Anonymous on Mon 28th Nov 2005 17:36 UTC
Anonymous
Member since:
---

All well and good. But, from the standpoint of getting stuff done, we need to figure out how to integrate a Gnumeric spreadsheet and an Abiword document, possibly querying something in an RDBMS, just because.
DBus sounds like great infrastructure--I'll follow anything Robert Love is working on based on his reputation alone. But the endpoints are as important as the line connecting them.

Reply Score: 0

Bonobo ?
by Anonymous on Mon 28th Nov 2005 18:07 UTC
Anonymous
Member since:
---

What about bonobo of GNOME ?

Reply Score: 0

RE: Bonobo ?
by MightyPenguin on Mon 28th Nov 2005 18:22 UTC in reply to "Bonobo ?"
MightyPenguin Member since:
2005-11-18

I think the evidence shows bonobo sucks. It's a great idea but somehow not too many people seem to be using it. This all becomes clear when you compare it to kparts or kio (sorry if I messed up the names) which just plain rock and work everywhere in KDE, while bonobo doesn't seem to have that level of ubiquity.

Reply Score: 1

RE[2]: Bonobo ?
by thebluesgnr on Mon 28th Nov 2005 19:22 UTC in reply to "RE: Bonobo ?"
thebluesgnr Member since:
2005-11-14

I'm not sure if Kparts being superior (if it actually is) has much to do with it; Nautilus doesn't use bonobo extensively by design (it's restricted to file managing, not web browsing, document viewing, etc).

Reply Score: 1

RE[3]: Bonobo ?
by Anonymous on Mon 28th Nov 2005 20:18 UTC in reply to "RE[2]: Bonobo ?"
Anonymous Member since:
---

Nautilus no longer uses Bonobo in any fashion. I believe Gedit is looking to remove Bonobo in the next major release.

So, GNOME is moving away from Bonobo and is focusing more on ABI stable shared libraries and in-proc plug-ins.

Reply Score: 0

RE[5]: Bonobo ?
by dsmogor on Mon 28th Nov 2005 22:27 UTC in reply to "RE[3]: Bonobo ?"
dsmogor Member since:
2005-09-01

That's pretty sad as Bonobo and it's primary component (Orbit2) started to look pretty decent (in terms of cpu and memory consumption) more or less at the same time Miguel lost interest in it.

Dbus is fine system service transport and notification mechanism but it's not comparable to BONOBO, which was made to serve different purpose (OLE on linux).
And failed, unfortunately.

I guess it shows a role of good documentation in success of a project (and a framework esp.).

Reply Score: 1

RE[4]: Bonobo ?
by kloczek on Mon 28th Nov 2005 23:55 UTC in reply to "RE[3]: Bonobo ?"
kloczek Member since:
2005-11-28

>Nautilus no longer uses Bonobo in any fashion. I believe Gedit is looking to remove Bonobo in the next major release.

Realy ?

$ ldd /usr/bin/nautilus | grep bono
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0x03f20000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0x021b9000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0x0211f000)

$ rpm -qf /usr/bin/nautilus
nautilus-2.12.1-6

Reply Score: 1

RE[5]: Bonobo ?
by Anonymous on Tue 29th Nov 2005 01:28 UTC in reply to "RE[4]: Bonobo ?"
Anonymous Member since:
---

Hmmmm... you're right: there's still some Bonobo lurking there. I was thinking of the removal of the Nautilus views based on Bonobo (in favor of plug ins). The developers are working on getting Bonobo out, though: http://mail.gnome.org/archives/nautilus-list/2005-October/msg00026....

At any rate, thanks for the correction.

~Andrew

kloczek spake:

>Nautilus no longer uses Bonobo in any fashion. I believe Gedit is looking to remove Bonobo in the next major release.

Realy ?

$ ldd /usr/bin/nautilus | grep bono
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0x03f20000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0x021b9000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0x0211f000)

$ rpm -qf /usr/bin/nautilus
nautilus-2.12.1-6

Reply Score: 0

RE[3]: Bonobo ?
by molnarcs on Mon 28th Nov 2005 21:12 UTC in reply to "RE[2]: Bonobo ?"
molnarcs Member since:
2005-09-10

"I'm not sure if Kparts being superior (if it actually is) has much to do with it;"

Kparts uses DCOP and DBUS was inspired by DCOP, that's why it was mentioned I guess. It would be wonderful if both KDE and GNOME used the same framework for communication between various services, but I don't know what plans KDE has. I have read some months ago that DBUS and DCOP serve the same purpose, and the latter being more mature and proven, at that time there was no intention to switch to dbus (dbus also was lacking in some areas).

Basically: DBUS intends to be what DCOP is (and was for a few years) for KDE, only it's a GNOME thing. There is some effort to make it appealing for KDE as well (standardizing on one framework is a nice idea) - but whether or not KDE4 will use dbus or not remains to be seen (again, this depends on many things: whether or not DBUS can catch up with DCOP by then, the difficulty of switching to DBUS, and afterall, it already has the functionality of DBUS in DCOP)

Reply Score: 1

RE[4]: Bonobo ?
by anda_skoa on Mon 28th Nov 2005 22:20 UTC in reply to "RE[3]: Bonobo ?"
anda_skoa Member since:
2005-07-07

KParts and DCOP are two different techologies.

An application can offer interfaces via DCOP or access other application's interfaces without needing to work with KParts and vice versa.

Reply Score: 1

RE[2]: Bonobo ?
by Sphinx on Tue 29th Nov 2005 20:55 UTC in reply to "RE: Bonobo ?"
Sphinx Member since:
2005-07-09

No, I believe it's CORBA that sucks, bonobo is just another implementation of it.

Reply Score: 1

v RE: Bonobo ?
by Anonymous on Mon 28th Nov 2005 19:52 UTC in reply to "Bonobo ?"
RE[2]: Bonobo ?
by BrianH on Mon 28th Nov 2005 23:22 UTC in reply to "RE: Bonobo ?"
BrianH Member since:
2005-07-06

You know that Bonobo is a piece of crap when:
...
3) it was developed by Miguel De Icaza


You forgot the rest of that sentence: "and even he doesn't use it anymore, having moved on to create even better things like Mono to replace it."

Reply Score: 1

RE[3]: Bonobo ?
by Anonymous on Tue 29th Nov 2005 23:21 UTC in reply to "RE[2]: Bonobo ?"
Anonymous Member since:
---

You forgot the rest of that sentence: "and even he doesn't use it anymore, having moved on to create even better things like Mono to replace it."

Just one thing on this: Despite his capabilities of presenting himself as the world's front inventor in the medias, he has only copied whatever he has found useful in the proprietary (MS/MAC) world (NortonCommander, WindowsExplorer, Photoshop, Desktops, Excel, C#, what's next?) but never invented a single piece on his own. He is overhyped, and his commercial attitude is unhealthy for GNOME.

Reply Score: 0

Bonobo is being obsoleted
by RenatoRam on Mon 28th Nov 2005 19:36 UTC
RenatoRam
Member since:
2005-11-14

Even the gnome project is moving AWAY from bonobo, afaik, so I don't think it's a good candidate.

Reply Score: 1

Anonymous
Member since:
---

I was very shure that somebody will ask what D-BUS has to do with Eclipse, and so on. This is not what the article is about. The article is not about how the projects compare. It is about how they will be used in future. What I wanted to put the finger at is that D-BUS will become dominant for service-like communication on free platforms like linux, and that the quality of this "link" will be compared to the quality of other strategies. This is why I think that D-BUS may not be thought for this but should be prepared for this. There is a project, and there's reality.

Reply Score: 0

The author: Ahh, and...
by Anonymous on Mon 28th Nov 2005 20:11 UTC
Anonymous
Member since:
---

When one of bonobo or kparts becomes an official project at freedesktop.org, there may be a sense in going with it. But, from my point of view, both are too highlevel. D-BUS can do that with an "address-book" (store, as one mentioned). The query should work similar to SQL (though easier and in D-BUS style: just calling the right address and getting an object with results back).

Reply Score: 0

*Sigh* so much missinformation
by Anonymous on Tue 29th Nov 2005 14:38 UTC
Anonymous
Member since:
---

Hello all,

I'm J5, a co-maintainer of D-Bus and release monkey. A few points to correct some of the things I have been seeing in the posts:

1) D-Bus is not a Gnome technology and in fact KDE, XFCE and others can and do use it to some extent. Gnome has just been quicker in adopting it.

2) Qt4 already has excellent bindings for D-Bus, Waldo is working on making it a DCOP replacement. It is up in the are if KDE will fully embrace it or use it along side DCOP.

3) D-Bus is just the lower level messaging facility, it is not comparable to COM or other larger frameworks. Frameworks should be built above it which is what this paper looks like it wants to do.

4) Robert Love did not write D-Bus. He has written other parts of the the stack such as gnome-volume-manager. Please read the AUTHORS file and give credit where credit is due.

To the author: have you checked out the queuing abilities of service names in CVS? It could for instance allow multiple multimedia apps to ask for the o.fd.mixer service which would make one the primary and the others part of the queue. If the primary goes away the next one steps up. You can even program each app to grab the primary when it is focused.

Reply Score: 0

RE: *Sigh* so much missinformation
by Anonymous on Tue 29th Nov 2005 23:02 UTC in reply to "*Sigh* so much missinformation"
Anonymous Member since:
---

The author:

Haven't seen the queuing abilities yet. They make me think, though. There is some general misunderstanding here. When you see all the postings about bonobo, com, and so forth, you may agree that the technocrats are just sitting on their worldview that everything is discussable in terms of apps and frameworks. I think that this is the old view. What you write about the queuing abilities has something of this old view too.

It's not enough to find a resource. And, when you look at my example in the article, a client should be able to access the full queue and determine how to use the registered entities. When all the faders just work how they like it, a client may not be able to use a single one. Another one has brought up the example with abiword and gnumeric. I think that this is already too high-level because the question is not if abiword is searching for a gnumeric table: it is about "client" scanning "clipboard" and detecting a table of type "gnumeric". Even that is too high-level because: will client be able to work with this table? If you look from the technocrat's perspective, this is a matter of the both apps. I disagree.

I think it is a matter of sane interfaces. Apps may register themselves as "full services" on the D-BUS network but they should also register their "resources" at other, well-known locations. They should do that like the others do that and provide the same interfaces. I don't think that this will come up if not somebody specifies a standard with general interfaces per resource-type.

Here lies the problem. Just searching, finding, and using only works if NEITHER (like you wrote) everything can just register any interface everywhere NOR app1 expects app2 on the line BUT only if the client is prepared to talk a standard that is supported by the service too. This is the mediating layer between the both apps. And it must be defined a sane way. Neither D-BUS nor the frameworks solve this a sane way. There will be concurrency and disfunction.

There "must" be some D-BUS framework specification that guides the developers to come together over D-BUS instead of doing only their own stuff (at least if one takes for serious what is happening in the world of ICT).

Reply Score: 0

Anonymous
Member since:
---

It's in draft and certainly in RFC phase. There exists a library that abstracts out the DBus part as well as for servers (players) and clients (e.g. control applets).

It is not directly what you'we discussed in your article, but we are heading towards this direction.

URL is: http://beep-media-player.org/index.php/MPRIS

Reply Score: 0