[MOBY-dev] comments on specification

[Martin Senger]

> The hackathon provided a wealth of ideas and went a long way to
> crystallizing (at least in my mind) what the "1.0" spec would look
> like.  It would be unfair (and possibly destructive to community
> buy-in) if we didn't provide something stable and usable in the next
> couple of weeks.
>
   Well said, Mark, and I second it on 100%.

> In this regard - any comments on the various aspects of the spec that
> have been described up to now should be made ASAP
>
   Here is few items we should clarify in the spec (most of them we had
already discussed during ther biohackaton, and they are not here in any
order of priorities):

   * How to define and later how to invoke a service that has multiple
inputs; shoud be some of them considered "primary" and some of them
"secondary" (for example the command line options would fall in this
category)?

   * Could a service have more than one output? I vote yes because of my
experiences with EMBOSS (some of those analyses have more outputs). I also
feel that having possibility for a specific "secondary" output may help to
combine services into a workflow (for example this "secondary" output may
be flag indicating success/non-success of a service invocation, or it can
indicate some branching conditions).

   * Could have the biomoby registry a way how to register additional
properties of the registered services? Something like having a way to add
name/value based properties which may be used (if correctly defined by an
ontologies) for describing the quality of service of registered services.

   * Could the biomoby registry spec include "server-push" type
notification to the registered subscribers? This is something what myGrid
project can benefit from, but also other users. But in the same time it
puts much more responsibility on the registry - so I am not sure about it.

   * Can a biomoby registry guarantee that registered services are
(reasonably) live and up-and-running? One way to do it - the way myGrid
suggested in its UDDI-M spec - is to introduce a "registration by lease".
The services - perhaps only those who choose such type of registration -
must re-register themselves after (or close before) a "lease" expires -
and if not, the registry forgets them.

   * Security aspect should be euther explicitly defined in the spec, or
the spec should clearly say that the security is the task of other layers
and not of the registry API.

   Martin

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger