Are you sure they are really compatible? DO forwards NSInvocations (incl. all parameter objects) to a remote end identified by a NSMach or NSSocketPort and returns results. It has provisions for specifying whether objects are transported byref or bycopy to optimize performance.
I have no very deep knowledge in DBus but my impression is that it has a different remote object addressing scheme and message model that is incompatible with NSInvocation forwarding. But I may be wrong and there may be a clever way to define a subclass of NSDistributedObject or something similar that references a DBus "objet" and can be easily used as an argument of on NSInvocation. Then, the "rootProxy" could reference DBus remote objects. Just my 2 ct, Nikolaus Am 11.06.2012 um 21:08 schrieb Jamie Ramone: > Just my 2 cents but wouldn't it be better to integrate DBus awareness > into the DO related classes (NSConnection, NSDistantObject, etc.) as > it's basically the same thing but written in C? I recently had to work > with DBus for the first time a few months ago and was astonished at > how similar it was to DO, and how it basically duplicated both > GNUstep's and Apple's effort in object oriented inter-process > communication, though failing a bit in the transparency dept. So what > I'd suggest is adding code to transparently handle communication with > DBus endpoints (I hesitate to use the word 'object' here). I believe > all that would be needed is to add detection code for an incoming > connection request to distinguish whether the solicitor is a GNUstep > object or a DBus endpoint for a server, and something analogous for a > client (detecting the server type, most likely via handshaking). With > a mechanism like this in place communication with DBus capable apps > becomes trivial. > > On Wed, May 23, 2012 at 8:48 AM, Niels Grewe <[email protected]> > wrote: >> Hi Ivan, >> >> Am 23.05.2012 13:35, schrieb Ivan Vučica: >>> Hi, >>> >>> On Tue, May 22, 2012 at 3:57 PM, Niels Grewe <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Fred and Ivan, >>> >>> Am 22.05.2012 08:32, schrieb Fred Kiefer: >>> > I don't think that libdbusmenu-glib is the way to go. We have a >>> > excellent DBUS interface in GNUstep and should build on that when >>> > implementing a theme that wants to handle menus that way. >>> >>> I second that, especially since the DBusMenu stuff has been on my todo >>> list for quite some time (though not at a very high priority). Basically >>> what you would need is a proxy that exposes the menu using the >>> com.canonical.dbusmenu interface [0] and instead of having >>> gnustep-gui/back doing the drawing and event handling for the menu, >>> you'd register that proxy with the com.canonical.AppMenu.Registrar D-Bus >>> service [1]. The global menu will then issue callbacks that drive the >>> menu. (At least that's my superficial working theory of how it >>> should work) >>> >>> >>> DBusKit would definitely be the cleanest way to go. >>> >>> However, an issue is possible breakage of the DBus interface on >>> Canonical's part. libdbusmenu-glib is probably less likely to be break. >> >> I don't think that is an real issue. If Canoncial (or, for that matter, >> any other company or project) defines and documents an API, I'd expect that >> >> a) the reference implementation actually adheres to the documentation >> b) it is kept stable for the forseeable future >> c) deprecation of functionality and other API changes only happen if >> there is a sensible reason for them and are communicated well in advance >> >> If you expect Canonical to be silly enough to not do that, I'd not even >> bother implementing the API at all. Otherwise, I'd prefer having a >> proper Objective-C solution for this. >> >> Cheers, >> >> Niels >> >> _______________________________________________ >> Discuss-gnustep mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > -- > Besos, abrazos, confeti y aplausos. > Jamie Ramone > "El Vikingo" > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
