[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: D-BUS versus GDOMAP (Was: D-BUS equivalent)

From: Richard Frith-Macdonald
Subject: Re: AW: D-BUS versus GDOMAP (Was: D-BUS equivalent)
Date: Tue, 31 Aug 2004 11:38:30 +0100

On 31 Aug 2004, at 11:08, MJ Ray wrote:

On 2004-08-30 17:24:44 +0100 Chris B. Vetter <address@hidden> wrote:

MJ Ray wrote:
Anyone know where gdomap's design docs are?
Use the source, Luke.

That's not very helpful. It ranks alongside "STFW" and "RTFM".

I think that's a little unfair ... as the design/rationale is documented near the front of gdomap.h His email may have been very terse, but it *was* accurate, as there is no discussion of internals/design anywhere else... it's a very simple, lightweight system. It's purpose is solely to map service names to ports
on a network-wide basis.

Anyway, been looking around. "man 8 gdomap" has an introduction: it also references GNUstep(7), which I don't seem to have. Where should that have come from?

I don't know about that ... perhaps the author of the documentation

The source is under gnustep/gnustep/core/base/Tools in CVS (not in Source as I first thought). gdomap.c has few comments. Running "autogsdoc gdomap.h" is not very helpful either.

I'm afraid gdomap predates autogsdoc by a long time.

There are some notes in a comment at the start of gdomap.h -- I suggest reading "HOW IT WORKS" before the top bit.

Is there an example of a GDO conversation somewhere?

Not that | know of ... I'm not sure what you would want in an 'example' anyway. It all rather depends on the viewpoint you are approaching with. The distributed objects mechanism is described reasonably in the NeXT documentation and also in the class documentation, though an overview really has to be inferred from the class documentation.

Anyway, the basic operation is  as follows:

Pre-conversation -
0a. Server registers an object as being available as the 'root object' on a particular port with a specific name.
0b. Client looks up a port by name.

Conversation -
1a. Client connects to the port and asks for the root object.
1b. Server returns proxy to root object
2a. Client then proceeds to send messages to the object
2b. Server sends message responses except where methods are declared 'oneway' 3. The server may also send messages to the client and have the client send responses. 4. Eventually, the client or the server disconnects by invalidating port or connection or just exiting.

Post-conversation -
On shutdown, the server unregisters the service name and port it used.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]