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.
Thread beginning with comment 66062
To view parent comment, click here.
To read all comments associated with this story, please click here.
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 Parent Score: 1

RE[3]: Bonobo ?
by on Mon 28th Nov 2005 20:18 in reply to "RE[2]: Bonobo ?"
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 Parent Score: 0

RE[5]: Bonobo ?
by dsmogor on Mon 28th Nov 2005 22:27 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 Parent Score: 1

RE[4]: Bonobo ?
by kloczek on Mon 28th Nov 2005 23:55 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 Parent Score: 1

RE[3]: Bonobo ?
by molnarcs on Mon 28th Nov 2005 21:12 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 Parent Score: 1

RE[4]: Bonobo ?
by anda_skoa on Mon 28th Nov 2005 22:20 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 Parent Score: 1