Charter for the VO Applications Interest Group

[Pierre Fernique]

Thomas McGlynn wrote:
> While I think the basic issue of discussing how
> software interacts is central to this group -- I'll
> try to think of some words to put in the charter --
> words like 'develop standards' that Alberto had in his
> first message worry me.
> 
> That's more the purview of the working groups, and in practice
> it's been very hard to update things that are indicated as standards,
> witness VOTable, and even something as simple as the Cone Search.
> 
> Should we look at more informal approach, where this group
> serves as a place where groups of two or three (or more) organizations
> can describe what they are doing to get their tools to work
> together?  Others would be free to either use the same
> approach, or to suggest enhancements or changes (or make changes
> themselves), but there wouldn't be a formal group imprimateur.
> 
> It seems to me that this is exactly how the discussion Alberto,
> Sonali and Ivo have been having has evolved.  First
> they discuss how a current set of tools interacts and then
> they begin to hash out a new approach that incorporates the old.
> Where this diverges from the working groups is the sense that
> we don't expect to wait till everyone is on-board with
> a given approach before some of us build tools that use the
> new ideas.   If a couple of them agree on what they want
> to do, I say they don't need the rest of us to approve --
> but I hope they keep describing what they are doing.
> This group lets us take a peek at what the new innovations are,
> and take advantage of what the innovators learn and build.
> 
> This is a bit more bottom up than the approach
> in the working groups and may give us a better chance to
> get practical experience with building things before we
> freeze the interface designs.
> 
> My thoughts here are not entirely worked out and so I may be
> babbline a bit here... What do others feel about this.
> 
>     Tom
> 
> 

I agree for this approach. It seems to be less productive than a general 
standard but by experience it gives generally better solution and a real 
flexibility really required for this kind of things. And a good standard 
can emerge of that.

About Ivo Busko remarks and its cursor example, with Aladin/VOPlot 
ExtApp interface, we encountered the same kind of issue that I resume 
like this : how to have both a general interface and a specific interface ?
We solved partially that by adding a general method "String 
execCommand(String cmd)" in the ExtApp interface. We assume that the 
application can react to a set of commands in ASCII. These commands are 
not predefined and depend of the application. For Aladin, they 
correspond to the script Aladin commands. For VOPlot, this method does 
nothing. This approach let's open the usage of the interface for closed 
interactions and also for other future usages (new commands...)
However it is not a strong link such Ivo speaked about (such as a cursor 
event generated by the other application).

Another point that I would discuss :
I notice that in the AVO prototype, it has been surprisingly very easy 
to incorporate together several tools with a very few discussions about 
interfaces... If we imagine the same kind of exercice not in Java, but 
in C, C++ or Fortran, I can imagine more difficulties (dynamic so 
libraries such in Netscape Plugins...). I don't try to sell Java, but I 
note that this kind of languages is really appropriated for this purpose.

Regards,
Pierre