From: Dave Millard (dem97r_at_ecs.soton.ac.uk)
Date: Thu 24 Sep 1998 - 11:42:26 CDT
I hope everyone who attended the 4.5 workshop has enjoyed mulling over
some of the problems we encountered; Sigi and I have been concentrating on
the performatives idea fits into the general OHP-Nav effort and in particular how we should proceed with the IDL and the common document.
At 4.5 we agreed on the following things:
We also agreed that the idea of describing communications, as expressed by performatives, was a good one. However we had difficulty seeing how this could be written into an IDL specification.
We believe that by re-thinking the performative approach and looking carefully at the 'Danish Proposal' we have found some possible ways forward which aren't compromises but actually powerful combinations of the two approaches!
Performatives deal with message flow not message content. The whole reason
that we originally proposed performatives was to provide an extensible
'cradle' (i.e. a layer, see figure in
http://www.mmrg.ecs.soton.ac.uk~sr/ohs/performatives/performatives.html) that the OHP-domain protocols such as OHP-Nav and later OHP-Tax and OHP-Space could fit into.
When a message is sent with an ask performative, for example, you do not have to understand the domain protocol to understand that it is a request for an action. Similarly when a message you send results in a performative error response, you know that the other component couldn't parse or understand it, even though that component may 'speak' an entirely different OHP-domain protocol or version.
In the same way that in the real world personal assistants may exchange and work with information on behalf of their bosses, without actually knowing the meaning of that information, in the OHP world components can use performatives to communicate in a standard way whatever the domain or version spoken actually is.
This is the aspect of performatives that Sigi and I hoped to preserve and still do not want to lose. However after some serious brainstorming we have decided that the performative proposal given at the meeting confused these higher level 'message primitives' with the application level 'OHP operations'.
So we will try and explain performatives again but in the light of our conversations and incorporating the Danish proposal. Below is an ASCII diagram showing the levels of OHP (I hope its come out OK!)
OHP-Nav | OHP-Tax | etc... ---------------------------- OHP ---------------------------- The Danish proposal represents OHP-Nav described in IDL. Yes, we includethe Creat-ed operations and all the other -ed operations! What this does is to
This is where performatives come in. The OHP layer (the cradle we mentioned earlier) sits underneath the OHP-Nav protocol and uses performatives.
As an example of how this works we could define two performatives initially, ask and notify. These are important as we always know that an ask is followed by a notify that contains the result of the ask (thus there are legal sequences of performatives). Alternatively a notify on its own lets us know that something has occured in the system.
Thus message flow could go as follows:
Now we can define our performatives independently of the OHP-Nav operations, be defining what they mean in terms of the 'content' they carry and by defining message flow.
notify - sent either as a result of an ask or as a sequence with an ask-stream. Alternatively can be a general notification about something that has happened. It expects no response.
error - this is a possible response for any message and lets the receiving component know that this component could not understand the previously sent message in the content. It expects no response.
cancel - can only be sent in regards to an ask-stream message and tells the server to stop sending messages regarding that ask-stream. It expects no response.
eos - can only be sent at the end of a sequence of notifys resulting from an ask-stream message. It expects no response.
unadvertise - can only follow some time after an advertise, it means it is no longer possible to subscribe to messages of the form in content; it expects no response.
subscribe - can only be sent if the content has been previously advertised and means: send this component all messages you see of the form in content; It expects no response.
unsubscribe - can only be sent if the content has been previously advertised and subsequently subscribed to, this means: no longer send me all messages of the form in content; It expects no response.
_(fwd link)_ We believe that this now allows us to talk about the performatives and the OHP-Nav actions independently. We could in fact agree on these actions and move on to writing the IDL definition of OHP-Nav. Unfortunately we need to define both OHP-Nav and the OHP or performative layer to be interoperable.
We see the following approaches to including performatives using IDL.
Sigi and I feel that we could do this in the proposed common document as performatives are essentially 'operations on' or 'context of' whatever domain actions they are carrying. We could use any of the above approaches and we are open to any other suggestions.
Look forward to hearing your comments,
Dave + Sigi.
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:21:08 CDT