MiddlewareAttributeExtensions

Chair for Computer Aided Medical Procedures & Augmented Reality
Lehrstuhl für Informatikanwendungen in der Medizin & Augmented Reality

THIS WEBPAGE IS DEPRECATED - please visit our new website

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:

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


Edit | Attach | Refresh | Diffs | More | Revision r1.6 - 23 Mar 2005 - 12:35 - NikolasDoerfler

Lehrstuhl für Computer Aided Medical Procedures & Augmented Reality    rss.gif