Next: instantiation
Up: CCC Names
Previous: address
The next attribute we use in naming applications is based on
hierarchical typing of the application and of the management
protocols. The type field is descriptive both of the protocol that is
being used and of the state of the application within the protocol at
a particular time. For example, a particular application such as vat
may use a private protocol to communicate between instantiations of
the application, so a vat type is defined, and only applications which
believe they can understand the vat protocol and are interested in it
would register themselves as being of type vat. An alternative
way of using the type field is to embed the finite state machine
corresponding to the protocol within the type field - thus a floor
management protocol could use types floor.management.holder and
floor.management.requester in a simple floor control protocol,
that can cope with multiple requests at once. A final way of using
the type field is to allow extensions to existing protocols in a
transparent fashion, by simply extending the type field by using a
version number. Some examples of these techniques can be found in the
examples given.
Some base types are needed to ensure that common applications can
communication with each other. As a first pass, the following types
have been suggested:
- audio.send - the application is interested in messages about
sending audio
- audio.recv - the application is interested in messages about
receiving audio
- video.send - the application is interested in messages about
sending video
- video.recv - the application is interested in messages about
receiving video
- workspace - the application is a shared workspace application,
such as a whiteboard
- session.remote - the application is interested in knowing the
existence of remote applications (exactly which ones depends on the
conference, and the session manager)
- session.local - the application is interested in knowing of the
existence of local applications
- media-ctrl - the application is interested in being informed of
any change in conference media state (such as unmuting of a microphone).
- floor.manager - the application is a floor manager
- floor.slave - the application is interested in being notified of
any change in floor, but not (necessarily) in the negotiation process.
It should be noted that types can be hierarchical, so (for example) any
message addressed to audio would address both audio.send and
audio.recv applications. It should also be noted that an application
expressing an interest in a type does not necessarily mean that the
application has to be able to respond to all the functions that can be
addresses to that type. Also, (if required) the CCC library will
acknowledge receipt on behalf of the application.
Examples of the types existing applications would register under are:
- vat - vat, audio.send, audio.recv
- ivs - ivs, video.send, video.recv
- nv - nv, video.send, video.recv
- wb - wb, workspace
- a conference manager - confman, session.local, session.remote,
media-ctrl, floor.slave
- a floor ctrl agent - flooragent, floor.manager, floor.slave
In the current implementation, the type field is text based, so that
debugging is simpler, and we can extend the type hierarchy without
difficulty.
Next: instantiation
Up: CCC Names
Previous: address
Jon CROWCROFT
1998-12-03