Current users:
guest (web)
guest (web)
Index
Scenarios
Screen Shots
Design Details
Meeting (Umer, Con, Philip) to discuss proxy UI design issues.
What information could be used in a proxy mission specification?
- Time. We did not discuss this in detail in the meeting, though I suspect there are subtleties here that need further examination. For example, will it be sufficient for the mission representation to (optionally) declare that it should be terminated if not completed at a particular time, like the unix
atcommand? Or should we support something more likecron, where active missions are pinged at specified intervals. - Event stream. It should be possible to specify some kinds of proxy missions in terms of specific modifications, represented by CORK
Changeobjects, independent of content object state. - Content object state. Other kinds of missions may require direct access to the actual content object. While there are security issues with giving mission representations access to the stream of events describing object modifications, the security implications of access to object state are somewhat greater.
Design issues:
- We should avoid forcing content object implementations to be "proxy-aware", e.g., requiring them to implement a specific interface in order to be watched by proxies.
- We should also avoid having to write content object class-specific mission specification UIs, though having this as an option might be a good idea.
- Handling event stream-based mission specification may be somewhat easier, since similar
Changeclasses are shared by lots of kinds of content objects.
- Handling event stream-based mission specification may be somewhat easier, since similar
- JavaBeans and AppleScript provide models of how this could be accomplished:
- Actual content object classes need no knowledge of proxies, though changes might be desirable to provide controlled public access to state that would not normally be made accessible.
- Helper objects (similar to JavaBean's
BeanInfoclasses) could be added that would provide meta-data describing watchable state and events. Where appropriate these helper could provide custom, content-specific UIs. - Standard UI elements could be designed that would use these helper objects to build mission specification UIs.
Open issues include:
- We still need to generate a list of plausable missions before we get further along on the design of mission representation and mission specification UI. (We may have at least started such a list in the Spring. Need to check the CoWeb.)
- Helper object interface needs to be fleshed out. Having a list of missions will help with this. It would be useful to design this in such a way that the information provided (in filtered, human-friendly form) by a helper object could also be derived programatically at runtime in cases where no helper object has been defined. (JavaBeans introspection is a model for this.)
- Given helper object interface design, UI elements for building missions based on the info provided by helper object needs to be designed. For example, if a helper object exposes state or event information with a given data type a set of UIs for specifying tests on that type should be designed. Tests on Strings and primitive types would be a good starting place.