On Tue, 10 Apr 2007, Mike Fitzpatrick wrote:
> On 4/10/07, Mike Fitzpatrick <mjfitzpatrick-at-gmail.com> wrote:
>
> Just to clarify: The whole point of this is to reduce the chance that
> Aladin, Mirage, DS9, XImtool, etc would all see fit to create their own
> mtype specific to the app. They can still do this of course, but if
> display.whatever works for each of them the sender is free to use
> any of them without change.
Right. This is a standard service/object model, with certain operations ("display", "load", etc.), which is defined for a certain type of data object ("image" in this case). Nothing wrong with that, and it is what is required for interoperable tools (components, apps, whatever). Of course it can be extended with tool-specific commands.
One interesting thing is doing this at a higher level of abstraction, with a more limited set of high level, whole-object operations defined (as in one of my earlier mails). This simplifies the interface and allows tools to directly manipulate the actual data objects, rather than merely be told what to do by the client application. The lower level (or sometimes dual) XImtool/DS9 type of interface, where we can do such things as load arbitrary data into frame buffers, is also very powerful, but requires a much larger interface, significant device state, etc. Both approaches are worthwhile, and both have their applications.
Even with a high level, whole-object interface, the client will need to know what tool it is talking to, to be able to sequence a series of requests.