International Virtual Observatory Alliance

Difference: IVOATheorySNAP (2 vs. 3)

Revision 32006-09-15 - ClaudioGheller

META TOPICPARENT	name="IvoaTheory"

SNAP

Participants

Claudio Gheller (chair)
Herve Wozniak
Laurie Shaw
others ...
Gerard Lemson

TBD

Issues and decisions, FAQ

Below follows a list of issues that have come up during the work on this projecr, the decisions that were taken to resolve them and the reasons why. This list will serve as a history of the development of the specification for those interetsed parties who were not closely involved in the process.

Which type of simulation is covered ?

Issue We have had many discussions about what type of simulations are meant to be published under the SNAP protocol. The original idea was that they should include simulations of "objects evolving in 3D space". This will allow a concept of spatial subset to be predefined, including various geometries (SPHERE, BOX).

Discussion Various parties argued that any simulation that can be expressed as a N-dimensional box could/should be included.

Resolution As of 2006-09-15 no resolution yet.
Action items are:
to find several realistic use cases of the more generic configuration space where a subset protocol would be useful (Herve).
Develop the data model and see whether there is place for more complex use cases (Gerard)

On which other prorotocol will we model SNAP

*Issue*
Original SNAP spec was heavily based on the old SIAP protocol. Is this correct ? Should we use a newer protocol ?

Resolution May 2006, Interop Victoria
In Victoria we decided to model ourselves on SSAP like protocols. This includes having a data model for structuring the metadata describing simulations for registration and discovery.

Added:

>
>

Support for data staging

Issue Due to the large size of data produced by numerical applications, usually data are not avaialble immediately. Data should be stored on a disk from which they can be downloaded separately

Discussion Various solutions have been discussed for the following items: 1. the staging "may" or "must" be supported 2. interaction between the service and the user 3. management of the staging service (multiple queries, expiration time...)

Resolutions Some indications provided on 15/09/2006.
Action items are:
1. Staging "may" be implemented if the server supports only data download. It "must" be provided if full snap service, with cutout function, is supported. In fact, in this case, the cutout action is expected to take a long time (more than minutes, up to hours) to be completed. 2. We expect to support simple interactions between client and service. The client can submit the request, delete it and check its status(pending, running, completed). Optionally expected times to complete various stages can be presented. All these actions are up to the user. Server can send messages to the users, but only in a very simple way (e.g. sending an e-mail that the data are available up to a certain date). Other methods could require single sign-on systems and then complicate and unpopular requirements to the users. 3. This is up to the service provider. However this features have to be published in registry using proper tags.

The details of all these points will be writeen in the Snap document (in preparation)

other ...

<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

View topic | History: r6 < r5 < r4 < r3 | More topic actions...