GEOS SDK TechDocs
|
| 
6 Inter-Application Communication
| 
6.2 GenApplicationClass Behavior
There is a major difference between sending a message within an application, and sending one to a different application. When you send a message from one object to another within an application, you know that the recipient exists, and you know the optr of that recipient. This makes it easy to send messages.
When you send a message to another application, however, you do not (at first) know any optrs to that application. In fact, you may not even know that the application is running. Often, all you will know is something like, "I want to send a message to
SpiffyWrite
".
GEOS uses a client-server model of inter-application communication. Every
GeodeToken
corresponds to a server. Whenever an application is launched, GEOS checks to see if there is a
server-list
corresponding to the application's token. If there is, GEOS adds the app's Application object to the server-list; if there is not, GEOS creates a server-list and adds the Application object to that list.
For example, suppose the user launches a single copy of
SpiffyWrite
; this application has a manufacturer-ID of MANUFACTURER_ID_SPIFFYWARE, and the token characters "SWRI". GEOS will check if there's a server-list for that
GeodeToken
. Let us suppose there isn't such a list; GEOS will automatically create one, and add
SpiffyWrite
's Application object to that list. The Application object is now said to be a
server
for the list.
Now let us suppose another application needs to contact
SpiffyWrite
; for example, perhaps a desktop program needs to print a
SpiffyWrite
file. It tells the kernel that it would like to be a
client
on the list for the token "{MANUFACTURER_ID_SPIFFYWARE, "SWRI"}". GEOS will check to see if a server-list for that token exists. If so, it will add the client to that list; this will cause a notification message (MSG_META_IACP_NEW_CONNECTION) to be sent to every server for that list.
Once a client is linked to a server, it can send a message to the server list. It does this by encapsulating a message, then passing the encapsulated message to the server-list. GEOS will dispatch the message to every server for the list; the server objects will receive it just like any ordinary message. (It actually passes the encapsulated message to the server object as an argument to
MSG_META_IACP_PROCESS_MESSAGE
; the server can then dispatch the message to the final recipient.)
This establishes the link between the applications. The client can pass an optr to the servers by putting it in the encapsulated message; a server object can then send messages straight to a particular object.
When a client no longer needs to communicate with a server, it unregisters itself from the server list. GEOS then sends a notification message to every server object.
Customarily, whoever allocates a global resource must also free it. For example, if a client might pass information to the server by allocating a global block, writing the data to the block, and passing the block to the server. The server should notify the client when the server is finished with that data; the client can then free the block. Similarly, if a server allocates a block to pass information to a client, the server should free the block.
There may be several servers for a given server list. For example, if three copies of
SpiffyWrite
were running at once, each of their Application objects would be a server for the same server-list. Furthermore, any object can make itself a server for any list. All servers will receive copies of every message sent to the server list. To distinguish between different servers for a list, every server for a list is assigned a distinct
ServerNumber
. If it chooses to, a client can specify that a message be sent only to the server with a specific number.
GEOS SDK TechDocs
|
| 6 Inter-Application Communication
| 6.2 GenApplicationClass Behavior