Fwd: Discover and start VO Applications (SAMP compatible)

Mon Feb 21 03:06:42 PST 2011

Dear All,

  I think that this is a really interesting topic, and I would like to 
share my thoughts and experience.

Within the context of the OPTICON-FASE project prototyping work 
(https://www.eso.org/wiki/bin/view/Opticon/WebHome), one of main issues 
we faced have been:

1. how to retrieve and install a package providing one or more 
applications/computational components (providing certain type of 
operations);

2. how to launch (activate) an application/computational task providing 
a certain operation (i.e. mapping a specific MType).

The first point can be addressed by defining a standard packaging 
system, which implies the definition of:

1.a. a well know structure of the package and the manifests describing 
its content (being XML of whatever);

1.b. a format to compress the package in a single archive (zip, tar, 
whatever);

1.c. a tool able to deploy the package and prepare it to be run through 
an execution framework;

1.d. a central packages/software storage service (like an "App Store"), 
useful to distribute and disseminate the astronomical software 
(compliant with the standardized packaging system).

The second point depends on the first, since it is possible to activate 
a task/tool providing a specific operation (MType) only if you can 
access a complete description of the packages (and the components they 
provide, the operations/MTypes they serve, and the parameters sets of 
each operation) that you have at your disposal, and this is an info 
provided at packaging level.

Whether the application activation is given at Hub level or through a 
separate Package Manager application I think is just a matter of choice: 
giving a look at the other RPC/Messaging systems we have that DBus 
provides the applications activation as a service included in the main 
daemon, while ZeroC's Ice and CORBA (if I'm not wrong) have a separate 
activation service.

If a concrete discussion on this matter is actually starting now, I 
think it would be really interesting and I would be happy to contribute 
to the discussion.

Best Regards,

   Luigi

Il 02/18/11 18:58, Mark Taylor ha scritto:
> 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

-- 

Luigi Paioro

INAF - IASF Milano
Via Bassini 15, I-20133 Milano, Italy

Phone  (+39) 02 23 699 470
Fax    (+39) 02 26 660 17
Site   http://cosmos.iasf-milano.inaf.it/luigi/