Fwd: Discover and start VO Applications (SAMP compatible)

[Mark Taylor]

Laurent,

something like this could be a good idea.

Regarding the registry issue: VOApplication has been renamed 
AplicationRegExt, and there was some discussion of reviving interest
in it at the 2010 December Interop.
See page 4 of Ray's closing plenary
(http://www.ivoa.net/internal/IVOA/PlenarySessionsDec2010/IVOADec10RWGPlenary2.pdf)
- requirements and use cases are of interest at this stage,
and this may be one such.

From the SAMP point of view: this functionality would not have 
to be handled by the hub.  It would be better done by an independent
launcher tool which connects to the hub in the same way as any
other SAMP client and knows how to start new applications that can 
deal with particular MTypes.  Therefore I don't believe there are
any implications here for the SAMP standard or hub implementations.

I've given this idea some thought before, but not got round to doing 
anything about it.  There are a number of different ways it could work,
but I think the best would be if the launcher just subscribed to
all MTypes that it has potential clients for, and when a message
comes in, maybe start up a suitable client and forward the 
message to it.  How you work out the "maybe" and "suitable" here 
are the tricky bits of course: I think the mapping of MType to 
started-client would have to be configurable by the user, perhaps 
by a popup menu or a config file or both; the initial settings 
or available options could be populated from the registry if 
something like ApplicationRegExt comes into being, but equally 
a default configuration could be supplied, so it wouldn't be
necessary to wait for ApplicationRegExt before having a working
model of this.

There are various other devils in the details: How do you know if
a tool is already running?  Can you start non-Java tools?
Does it matter that the message is forwarded by the launcher
rather than from the original sender?  Etc.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

On Tue, 15 Feb 2011, Laurent Bourgès wrote:

>  Dear VO members,
> 
> We are working at the JMMC on client applications for the optical
> interferometry using VO and in particular SAMP : Aspro2 (interferometric
> observation preparation tool), LITpro (model fitting) and SearchCal (search
> star calibrators for a particular target). Our applications use standard
> message types (load.votable) and custom messages to deal with our particular
> needs.
> 
> We are looking for a solution to launch VO applications that are able to
> deal with SAMP messages directly without asking the user to start manually
> required applications ...
> Indeed, there is no standard mean to launch a SAMP application from another
> client application :
> - Aspro2 => SearchCal and LITpro
> - SearchCal => Aspro2, Aladin and any SAMP application supporting VOTable
> containing a star catalog
> - LITpro => topcat (VOTable and FITS)
> 
> One solution can use the fact that all these applications are supporting
> Java Web Start : it is possible to launch such applications using the
> command : 'javaws http://host/application.jnlp'.
> 
> However it requires that the client application has the knowledge / meta
> data like :
> - application name
> - application URL (jnlp)
> - description
> - supported SAMP message types
> ...
> 
> It looks like a registry entry describing any VO SAMP application and also
> extends SAMP Application meta data.
> 
> The well known Aladin (CDS) has already this feature using GLU (CDS specific
> registry implementation).
> Moreover it can also install and launch any application using a custom
> command line.
> 
> Here is a screen shot of the VOTool window :
> [image: Aladin VO Tools]
> 
> I would like to know if you consider this feature should be covered by VO
> standards.
> 
> According to me, it has several impacts on existing standards :
> - Registry : provide VO applications descriptions with SAMP capabilities :
> SAMP capabilities are already described by the SAMP protocol but only
> available at runtime (via the hub).
>         What is the status of the VOApplication extension to VOResource ?
> 
> "VOApplication is a registry extension schema that allows one to register
> applications, tools, and libraries. A working draft of a document defining
> the extension schemas for describing applications is under development at
> RegDMApplications<http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/RegDMApplications>.
> 
> 
> At the Fall 2009<http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/InterOpNov2009Reg>Interop,
> the Registry Working Group agreed to table the development of this
> schema until a stronger driver emerges. Contributions and comments are still
> welcome; *we are particularly interested in use cases that need the ability
> to dynamically discover applications*."
> 
>  - Application / SAMP : The SAMP hub could handle the discovery of
> applications supporting SAMP message types (registry client) and launch the
> needed application. This requires important changes in existing SAMP
> libraries but applications using those could take advantage of this new
> feature.
> 
> 
> Finally, having VO applications in the registry could help us providing a
> new client or web application to discover, browse and install VO
> applications to novice users and help them using the VO (like ubuntu
> software center : http://en.wikipedia.org/wiki/Ubuntu_Software_Center).
> 
> Best regards,
> Laurent
> 
> -- 
> Laurent Bourgès
> Software engineer
> JMMC - LAOG - CNRS
> France