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

AttributesChanged interface

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.

Methods:

• void attributesChanged(in Attributes attributes)
• or: void attributesChanged(in Attributes attributes, in StringSeq^? whatChanged) (unnecessarily complicated?)

Extension of Attributes interface for registration:

• void registerAttributesChanged(in AttributesChanged subscriber)
• void unregisterAttributesChanged(in AttributesChanged subscriber)

Implementation issues:

• Called by the AttributesHolder^? object within the service manager.
• Threading:
  • 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

Future ideas

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

Inherited attributes

• 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.

-- AsaMacWilliams - 30 Jan 2004