From freedesktop-dbus Tue Jan 25 10:41:23 2005 From: Waldo Bastian Date: Tue, 25 Jan 2005 10:41:23 +0000 To: freedesktop-dbus Subject: Re: D-BUS implementing DCOP - some minor problems? Message-Id: <200501251141.28271.bastian () kde ! org> X-MARC-Message: https://marc.info/?l=freedesktop-dbus&m=117323211627864 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1131859.VyB6oCzuKz" --nextPart1131859.VyB6oCzuKz Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 25 January 2005 06:17, David A. Wheeler wrote: > I spent a little time comparing the DCOP and D-BUS documents, > to see if DCOP could be re-implemented using D-BUS. > In a very few areas, the current D-BUS draft doesn't seem to currently > support what's needed to reimplement DCOP (which would really > simplify transition if KDE decided to do it), or at least I > wasn't sure. The problems do look like they'd > be trivial to solve. Here are the potential semantic mismatches > I could find, please let me know if I'm mistaken: > > * DCOP method names include not just the name as you'd expect, > but the parameter list using the local type names. > For example, "doIt(int)" is treated as a method name in DCOP. > In contrast, D-BUS doesn't permit parentheses or commas in > method names -- D-BUS would use "doIt" as the method name. > Also, note that method names "doIt(uint)" and "doIt(pid_t)" > are _different_ in DCOP (they're considered completely > different methods, even if the underlying types sent over > the wire are the same). It's not clear if this > kind of differentiation is actually employed. > > Recipients of a DCOP call DIRECTLY compare for equality against > these longer strings (e.g., they compare to see if they > received a call for "doIt(int)")... so DCOP APIs are > required to provide these longer names to the message receiver. > That's important, because that means that if D-BUS simply > strips off the parameters (e.g., "(pid_t)") to create a > legal D-BUS message name, there's no way on the DCOP > recipient end to reconstruct the message in a way > that the recipient will understand it. > > For a simple transition, D-BUS would somehow need to > have a way to transfer the parameter list types in the message. > This could be done by relaxing the rules on message names > (so "doIt(int)" is legal, as well as "doIt"). This would allow > D-BUS to directly support the same approach used by DCOP. > Another solution would be to define a new field to capture the > parameter list ('parms' field "(int)" or whatever), so that > this DCOP data would be included in the message. > You _could_ handle this by quietly adding a new parameter in > the body with this info, but I think that'd be really ugly... > that kind of info belongs in the header, not the body. I don't think we should try to map DCOP onto DBUS 1:1. The idea is to gener= ate=20 native DBUS calls (from the *.kidl files) instead of DCOP calls in KDE 4 wi= th=20 some legacy support for old-style DCOP calls. It wouldn't be possible to ma= ke=20 calls into DBUS from old-style DCOP code, or make calls into old-style DCOP= =20 code from DBUS. The only thing we would do would be to wrap old-style DCOP= =20 calls in some DBUS call and unwrap it at its destination so that old-style= =20 DCOP code can continue to call other old-style DCOP code. This has been discussed in some more detail in=20 http://lists.kde.org/?t=3D109646896300003&r=3D1&w=3D2 In particular http://lists.kde.org/?l=3Dkde-core-devel&m=3D109647704712328&w=3D2 > * The DCOP "send" interface doesn't > indicate whether or not a reply is expected, so it's hard to > set the relevant D-BUS flag with confidence. DCOP "send" doesn't expect a reply by definition, only "call" does. > However, send by itself doesn't block, so it could probably > just always set NO_REPLY_EXPECTED; the recipient could ignore that > flag if they really have data to reply. The problem here is that > DCOP doesn't provide enough data, but it's not clear that this > would really cause any trouble. > > * DCOP has two different kinds of connectors, "volatile" and > "non-volatile". For volatile connections, if a sender > OR receiver is deleted, the connection is deleted. Although it seemed a good idea at the time, I don't think that "volatile"=20 connections are actually used. > It's not clear to me from the current D-BUS documents > how signal recipients are selected, so it's hard to > determine if D-BUS can do enough. > The DCOP documents seem to imply that signals are only > sent to a single recipient > ("It can be connected to _a_ function..."), but I doubt that's > actually true (if true, that's a very unfortunate limitation > that D-BUS can get rid of). No, the whole purpose of signals is that it can have muliple listeners. You= =20 connect the signal to a single function at a time, but by connecting it=20 multiple times to different functions it will result in multiple functions= =20 being called. > * DCOP's "send" can actually do a broadcast to a set of applications, > e.g., sending to 'konsole-*' will send to all apps called console. > D-BUS should implement a 'limited broadcast'; I wouldn't be > surprised if it does, I just don't see anything about it. > It doesn't appear that "send" should send a signal, because > it CAN receive replies. > According to the DCOP documentation "You cannot call() a method > belonging to an application which has registered with a unique > numeric id appended to its textual name..." -- if that's true, > that's an unfortunate weakness in DCOP that D-BUS corrects. > I suspect I'm misunderstanding something here though. Where did you read that? That doesn't make sense, but maybe I'm missing som= e=20 context. Maybe it tried to say that you cannot use wildcards (e.g.=20 "konsole-*") in a call() Cheers, Waldo =2D-=20 bastian@kde.org | Free Novell Linux Desktop 9 Evaluation Download bastian@suse.com | http://www.novell.com/products/desktop/eval.html --nextPart1131859.VyB6oCzuKz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQBB9iJYN4pvrENfboIRAhFXAJ46pm9F1/E6uRD6HGyB8bS5yDj9rACfbPJe TozTKkF2KKbVMbh5c9Tfk2M= =rQPK -----END PGP SIGNATURE----- --nextPart1131859.VyB6oCzuKz--