Soton IDL proposal

From: Sigi Reich (sr_at_ecs.soton.ac.uk)
Date: Fri 23 Oct 1998 - 10:31:00 CDT



Dear all,

Dave and I have come up with a slightly different proposal for an IDL for OHP-Nav. It is based mainly on the Danish proposal, on our existing (modified) XML specification and on the previously mailed performatives specification.

We believe that the main issues include

- whether we support querying (and at what level)
- whether IDs are assigned by servers or clients
- which functionality is to be done by computations (services)

Any comments warmly welcome!

Dave & Sigi


/**************************************
 * Soton Proposal for an IDL for OHP-Nav
 * Dave & Sigi
 * 23 Oct. 98 

#include "ohpdatatypes.idl"

  struct MetaInfo {

        string sender; 		//name of the sender
        string receiver; 	//name of receiving component
        string MID;		//unique message ID (unique to sender)
        string reference;	//message ID this is referring to
        string session;		//name of the session	
        string user; 		//user ID virtual cliens?
        string FID; 		//functional ID for parsing  la Dr. Pete N.
        string domain; 		//such as OHPNav, OHPTax
	string version;		//such as "OHPNav 1.0.Soton"
	string context;		//the context object ID of this message
	string performative;	//for usage of advanced systems, e.g. Solent ;-) 
  };

interface OHPNav {     

//A basic question arises: who assigns IDs? Danes believe clients should assign
//unique IDs; Sotonians believe this should be done by the server.
 

//Question No. 2: where does the meta-information (-> message header) go in
//the IDL spec?
  

//We would suggest a general functions that would take AbstractObjects (or
//any instance of a derived class);

  void create(in AbstractObject o, in MetaInfo mi);   void created(in AbstractObject o, in MetaInfo mi);

//Issue with "delete": do we pass the whole object? It is not necessary (ID would be
//sufficient and simpler) but sometimes it might make sense to have information
//on the whole object. Dave suggests a hybrid approach: delete takes ID whereas deleted
//takes whole object:

  void delete(in string objID, in MetaInfo mi);   void deleted(in AbstractObject o, in MetaInfo mi);

  void modify(in AbstractObject, in ModType modtype, in MetaInfo mi);   void modified(in AbstractObject o, in MetaInfo mi);   

  void retrieve(in string ID, in MetaInfo mi);   void retrieved(in AbstractObject o, in MetaInfo mi);

//Querying is a complicated issue!!!
//This is why we have left it out in our proposal. We think that it would be
//nice to have a standardised way to query in OHPNav; however, we don't really
//see a way of expressing application independent queries (even though the datamodel
//might be standardised): we cannot assume either SQL or OQL or any other
//language. The current (Danish) proposal allows for very basic querying on sets of
//objects of the same type. This means that one could not specify queries such as e.g.
//"Select * from Node where Node.contentSpec.mimeType == text/html".

//We can imagine an optional, standardised query service. This service
//would take a server specific query string (e.g. SQL or OQL or any system specific
//query language) and return a list of object IDs. It would be optional but if
//a component would support it, then its behaviour is well defined. This allows
//for much more powerful queries but could only be used if the client understands the
//query language!

//specific comments
//numMatches: this is an interesting thing. We are not sure whether it is a good idea
//to define the number of hits on attributes that have to match in order to make
//the object a match. We would assume that the client does only query those attributes
//that it is actually interested in. "Randomly" selecting objects does not seem
//convincing. And also, the query mechanism is basic and we therefore should
//keep it as minimal as possible.
//falgs: could it be that a "flags" parameter is missing in the navserver.idl, e.g. in
//void contextQuery? Or do we assume that the server side is intelligent enough to
//parse the passed on set of objects ("patterns") to see which ones are relevant?

//Note that InParamSet and OutParamSet have to be specified in IDL still
  void executeService(in string serviceSpecID, in InParamSet inparams, in MetaInfo mi);   void serviceExecuted(in string serviceSpecID, in OutParamSet outparams, in MetaInfo mi);   

//We are unsure whether an additional PSpec is needed (an Anchor already has a PSpec);
//If it is included then the client must presumably combine the two PSpecs before
//displaying the anchor.

  void displayAnchor(in Anchor anchor, in PSpec combiPSpec, in MetaInfo mi);   void displayNode(in Node node, in PSpec combiPSpec, in MetaInfo mi);

//this was getServices; Its existance is due to the fact that we want to get a list
//of services (computations) without specifying any params. This is answered by
//a retrieved which delivers a list of services (computations) to the client.
//An issue here is how to actually return a list of service objects. Would this
//be done with a temporary context?

  void retrieveComputation(in MetaInfo mi);   

  void closeNode(in Node node, in MetaInfo mi);   void error(in string subject, in string message, in MetaInfo mi);

//linkFollowFromLocSpec et al.
//We would have envisaged this as a standard service because the server may
//not treat it as a simple query. Thus the functionality is opaque to the client
//and therefore this has to be a service.
//The same holds true for linkFollowedFromEndpoint, nodeLinksRetrieve,
//nodeEndpointsRetrieve;
//What concerns the compId we are not sure whether this should be in there. As
//discussed at the working group meeting it is not clear when computations
//should be run (before the following of a link, after, during, etc.)
  

//In addition to that we have suggested the services
//getRelevantNodes (returns a list of "starting" nodes)
//showLinks (returns all the links in which this node appears; so you could do
//e.g. fluid links. This could be realised by modifying nodeLinksRetrieve.
};



Sigi Reich
Multimedia Research Group
Department of Electronics and Computer Science, Bldg. 59 University of Southampton, Southampton S017 1BJ, UK phone +44 (0)1703 59 6505 fax +44 (0) 1703 59 2865 email sr_at_ecs.soton.ac.uk http://www.mmrg.ecs.soton.ac.uk/

This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:21:09 CDT