Planned changes to the middleware regarding Attributes
These are some ideas about extensions to the middleware regarding attributes. I hope to implement some parts of this in February. -- AsaMacWilliams
- 28 Jan 2004
Visible to services
To be Implemented by:
- Services: lets a service know when attributes of its service description change.
- Registered Needs within services: lets a service know when attributes of its need descriptions change.
- Perhaps this should be called when the predicate changes, too.
- Registered Abilities within services: lets a service know when attributes of its ability descriptions change.
- Sessions within services; e.g. implemented by object returned by newSession(). This lets services know when their communication partner changes.
- Sessions within the service manager. This reduces getAttribtues() traffic between service managers.
- DIVE DwarfSystemModel?, to be notified of changes to attributes of services that are currently being looked at.
- Note: DIVE also needs information of more general changes, such as new services. But perhaps not as frequently.
- void attributesChanged(in Attributes attributes)
- or: void attributesChanged(in Attributes attributes, in StringSeq? whatChanged) (unnecessarily complicated?)
Extension of Attributes interface for registration:
- Called by the AttributesHolder? object within the service manager.
- Send out all changes at once (easy, implement first), or
- wait a while and do batch updates no more frequently than once a second, from a separate worker thread (either one per service description, or only one for all attributes). Perhaps just add a doWork() method to the AttributesHolder?, or make it a Worker.
- Need internal callback to detect when attributes have changed
- Or just put in setAttribute - keep it simple
Evaluation based on attributes
- As suggested in middleware paper
- For propagation of attribute changes
- e.g. <ability>
- <attribute name="ThingId" eval="$(user)Head">
- Check out previous work done on similar project
- Check out exactly what it is needed for
- Put implementation in AttributesHolder?
- e.g. evaluate(in string formula) method
- Allow automatic reevaluation - add setFormula in addition to setAttribute()
- Check out spec from middleware paper
- Syntax: can this be extension of LDAP syntax?
- This would let us use the same method for evaluating boolean expressions!
- That would let us use much fewer SLP querys!
Better propagation of attribute changes
- Don't just create new clones for each partner
- Extend xml spec for needs to allow bound attributes
- e.g. <need>
- <attribute name="partnersMarkerId" bind="MarkerId">
- <attribute name="ThingId" bind="Marker$(partnersMarkerId)">
- Propagate attribute changes frequently, base on AttributesChanged
- Call setAttribute() on need when attributeChanged() of session is called from other side - but perform diff to stored attributes
- This would lead to perhaps more powerful and elegant implementation of attribute change notifications for sessions (see above) of services
Distance functions for needs
- Extension of NeedDescription? interface / xml
- e.g. <need>
- <dimension attribute="user" compare="$(user)" weight="2">
- <dimension attribute="ScreenWidth" scalemin="0" scalemax="800" weight="4">
- Compare to own attributes, 0 or 1
- Compare to fixed string, 0 or 1
- Compare to number; value scaled between 0 and 1 according to min and max
- Use to compute distance function for matching of abilities to needs
- Later: can be used in ubitrack for distributed error function evaluation
- Good way of documenting default selection strategy
Internal implementation issues in service manager
Allow duplicate setupSession() calls
- This should eliminate the "session already set up" bug
- Simply return the endpoint again
- Use this as active keepalive rather than the getAttributes() call
- Also use this (later) to allow changes to the communication endpoint
Call replacePartner from DefaultServiceSelection?
- Thereby re-evaluate distance functions more frequently
- Eliminate sporadic selection of wrong partner, just because it was found first
Command line properties to service attributes
- For each command line property
-Dname=value, the CorbaInit? helper sets the corresponding attribute in the service description
- The service can then query its attributes via getAttribute rather than from the commandlineprops helper
- This way, anything that can be specified in the XML file can be specified in the command line (and vice versa)
- Is registerService() early enough, or should we pass the values to CorbaInit? earlier?
- This is quite simple, actually
- Must be implemented in C++, Java, Python
Converters for protocols
- Allow translation e.g. between shared memory and video stream
- Allow translation between attribute changes and events, e.g. for configuration - this should be most useful
- Translation from attribute changes to events is good for notification e.g. of DIVE, too... or communication e.g. between service managers
- Allow translation between events and method calls (difficult)
Meta-information on same level as payload data
- This allows mixing of levels - more powerful systems
- One way of implementing: base on converters between events and attribute changes
- Suggestion by Gerhard Reitmayr
Mapping of complex data types to attributes
- Use this for configuration services?
- Persistent mapping e.g. of Anys to XML
- There already should be a standard for this (as in soap)
- Could even be used e.g. to specify a pose for the camera viewpoint in a service description for a viewer
- Document "fallback" behavior
- Services should inherit attributes from their service manager, too - e.g. hostname, username
XML parser: stop on contradiction
- when a service xml description has an attribute such as "hostname" that does not match that attribute of the service manager, the service description is not activated.
- That allows e.g. the sound service to be started only on atbruegge41, e.g. for sheep.
- 30 Jan 2004