Fwd: Discover and start VO Applications (SAMP compatible)

[Douglas Tody]

Hi -

As Luigi mentions we have looked into this issue in connection with the
OPTICON grant funded FASE project (aka applications framework).  This
gets into the issue of desktop frameworks for running packages/tasks.
SAMP is used for basic messaging.

Since this sort of thing runs in a local desktop environment rather than
on the Web I doubt if registering applications in the Registry is quite
the right approach.  Rather we need to install applications, or
applications packages, into the desktop framework which can then run
them.  It takes quite a bit of information about applications and their
dependencies to do this.

The better role for the VO Registry is probably for the "app store"
capability.  That is, we have a standard packaging mechanism for
astronomy applications or tasks, to allow applications software to be
easily downloaded and installed into the desktop environment.  This
packaged application software is then what would be described in the
Registry.  An app-store type application could then be provided to query
the Registry for software of interest, and then download it and install
it into the local environment.

It takes a fair bit of functionality to do this; this is exactly what we
have been looking into for the FASE/applications framework project.

Within VAO we have further work in this area planned to go forward next
year, as part of the desktop integration science initiative.  It would
be great to have some work on broader standards in this area, e.g. for
packaging, task/param interface, task execution and management (this is
where SAMP and task invocation come in), and so forth.

 	- Doug


On Mon, 21 Feb 2011, Luigi Paioro wrote:

> 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/
>