From kde-core-devel Tue Jan 25 12:49:49 2005 From: "Maksim Orlovich" Date: Tue, 25 Jan 2005 12:49:49 +0000 To: kde-core-devel Subject: Re: D-BUS implementing DCOP - some minor problems? Message-Id: <10235.24.59.105.96.1106657389.squirrel () 24 ! 59 ! 105 ! 96> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110665740619355 > 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. > > I don't think we should try to map DCOP onto DBUS 1:1. The idea is to > generate Please do remember that we rely on overloading extensively in some spots, though. >> * 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. Those the D-BUS equivalent of answering a DCOPSend would have to be able to send a dummy/void reply... The trickier part may be what DCOP inappropriately calls transactions --- deferred reply, including callback in a client, partly because the behavior is somewhat complicated, and partly because the D-BUS spec provides absolutely no semantics. > >> 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" > 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 > connect the signal to a single function at a time, but by connecting it > multiple times to different functions it will result in multiple functions > being called. There is no level for low-level support for signals, anyway. The DCOP ones just work by making calls to DCOPServer, and the server making calls to clients, pretty much. > >> * 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 > some > context. Maybe it tried to say that you cannot use wildcards (e.g. > "konsole-*") in a call() I am guessing here it's referring to the requirement that you use app-pid even if there is one of app, which was a bit of a change a while back.