strawman, applications software metadata

[John Taylor]

Thomas McGlynn wrote:

>
>
> E.g., I think we need a field with the semantics something like:
>
>    SoftwareType has the possible values "Library", "Application", 
> "Service"
> (and perhaps others).
>
I agree that we need to be able to register "desktop" applications.  
Like Paul, I'd like the registry to be machine-readable in that I want a 
registry client to be able to locate a suitable application and offer to 
download and install it automatically.   So, I'm interested in what 
download&installation meta data we need to store.  One particularly easy 
case is when the application in question is java web-startable, but I 
think we could probably do something similar when the application uses 
other deployment methods.

>
> Both applications and services should have some mechanism for defining 
> the interface
> to the tool, e.g., something that plays the role of WSDL.   I'm not 
> sure we
> want to use WSDL itself in this role, but for the moment I just think 
> we need
> a placeholder in the metadata for whatever it is that will describe 
> the interface.
> So you might have a:
>     InterfaceURL
> field for applications and services and I suppose we could do this for 
> libraries too.  I'd
> suggest making the InterfaceURL mandatory for Service, strongly 
> recommended for applications
> and optional for libraries.
>
> This ties back naturally to our existing registry entries for various 
> services.
> to encompass all of the existing ConeSearch, SIAP and SkyNode 
> services.  We only need to update
> those with some description of their interface and I'd hope we could do
> that by pointing to some standard document for each service type.
>
> There are as many as four URLs defined for a piece of software:
>
>     ReferenceURL:  links to definitive descriptions/documentation of 
> the software (always required)
>     DownloadURL:   links to a download capability for the software 
> (required for Library/Application optional
>                    for Services)
>     InterfaceURL:  links to a description in some TBD standardized 
> format for how the software
>                    is invoked (required for Service, recommended for 
> Application, optional for library)
>                    Many services (e.g., all cone search services) may 
> point to the same InterfaceURL
>                    (Perhaps an interface URL can be assumed for 
> certain service types?)
>     ServiceURL:    links to a URL that invokes a service (mandatory 
> for Service, not supplied for
>                    Library or Application
>
I think that a serviceURL _could_ sometimes be used for an application - 
Java Web Start apps can be launched by browsing to a URL  Perhaps in the 
case of other deployment/installation methods it could also be used: for 
example
<serviceURL os="Windows">
   file:// %INSTALL_DIR%/foo.exe
</serviceURL>

> Going beyond the pure registry, we may also want to consider what it
> means to register software.  I really think the way to get this to work
> is to make sure it works for non-interactive applications.
> So for library and application downloads, one detail that needs to be 
> considered
> is how we accommodate different versions of the software for different 
> architectures.
> We could modify the service URL in some standard way (with a 
> controlled vocabularly
> for supported architectures).  Or we could consider something like 
> what we do
> with SIAP and SSAP services and the ServiceURL could return a table 
> has a row for
> each of the supported architectures (and columns designating which 
> architecture
> each row corresponds to).

At the risk of sounding like a Java Web Start obsessive, again I think 
we can take a look at the format of JNLP files and see what we can learn 
from them.  For those who aren't familiar with them, they can include a 
set of platform-specific resources and the client only downloads and 
installs the appropriate one: e.g.
    <resources os="Windows">
      <nativelib href = "natives-win32.jar" />
    </resources>
    <resources os="Linux">
      <nativelib href = "natives-linux.jar" />
    </resources>   
    <resources os="SunOS" arch="sparc">
      <nativelib href = "jogl-natives-solsparc.jar" />
    </resources>
    <resources os="SunOS" arch="x86">
      <nativelib href = "jogl-natives-solx86.jar" />
    </resources>
    <resources os="Mac OS X">
      <nativelib href = "jogl-natives-macosx.jar" />
    </resources>     

I believe there's some doubt over whether a JNLP file's categorisation 
of operating systems is fine-grained enough, but this could be a 
starting point.

> Hope this isn't getting too complex too quickly!
>
Oh I'm sure there's plenty more scope for that!

John


>
>     Tom
>
>

-- 
===========================================================
VOTech (DS6: Data Exploration)
http://wiki.eurovotech.org/bin/view/VOTech/DataExploration
Tel: +44 131 6688329
Skype: johndavidtaylor
http://wiki.astrogrid.org/bin/view/Main/JohnTaylor
===========================================================