SAMP RFC: MType list

Jesus Salgado Jesus.Salgado at sciops.esa.int
Fri Jan 23 07:53:27 PST 2009


Mark,

I also agree to take the pragmatic approach for the time being and this
should not be a showstopper for the SAMP REC process.

Thanks for your work,
Jesus

On Fri, 2009-01-23 at 16:34 +0100, Christophe Arviset wrote:
> Mark
> 
> I understand well the point and view and indeed, we can start with this 
> pragmatic (and flexible) approach and introduce more formalism only if 
> need arises.
> 
> So I full agree with the document and proposal ! Thanks for all the work 
> and for your patience answering my questions :-) !
> 
> Cheers
> 
> Christophe
> 
> Mark Taylor wrote:
> > On Thu, 22 Jan 2009, Christophe Arviset wrote:
> >
> >> Mark
> >>
> >> Thanks for your answer. Indeed having the MTypes documented in some 
> >> SAMP specific web pages will solve the "visibility" part of the 
> >> question.
> >>
> >> But I may have an other question about the process on how MTypes get 
> >> added / removed / updated to that list?
> >> On one side, we need to have some flexibility for these changes and I 
> >> do NOT advocate to go through the standard REC process.
> >> But on the other side, we also need to have some level of formality 
> >> to control these changes.
> >>
> >> What are your views on this ?
> >
> > My personal view is that it makes sense to continue to use an informal 
> > approach unless and until we see some reason that it's inadequate or
> > problematic.  Up till now, apart from visibility which as you say I 
> > hope will be solved by using a persistent URL as I've suggested, the 
> > simple wiki page, with discussion on the apps-samp list, has worked 
> > fine. A wiki page
> > (http://eurovotech.org/twiki/bin/view/VOTech/PlasticMessagesProposal)
> > also worked well for the same purpose with PLASTIC.
> >
> > Perhaps some additional structure (e.g. one page for stable MTypes and 
> > one for more experimental ones) could be of use, but having it wiki-based
> > makes it easy to adjust the level of structure as such requirements 
> > become
> > clear.  The list of MTypes is explicitly intended to be extensible, 
> > and I think that making it easy to add to and modify (in 
> > backwardly-compatible
> > ways) MTypes is a Good Thing.  I'm not convinced that the additional 
> > layer of procedure required even by documenting these in an IVOA Note 
> > has much to offer for now - but I'm open to the idea that it might
> > do depending on how SAMP usage and take-up progresses.
> >
> > However, I'm prepared to have a debate about this if other people 
> > disagree.
> >
> > Mark
> >
> 
-- 
Jesus J. SALGADO                       Jesus.Salgado at sciops.esa.int

ESAC Science Archive Team
European Space Astronomy Centre (ESAC)
European Space Agency (ESA)

European Space Agency/European Space Astronomy Centre
P.O. Box 78
28691 Villanueva de la Canada                 Tel: +34 91 813 12 71
Madrid - SPAIN                                Fax: +34 91 813 13 08
-------------------------------------------------------------------


================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================



More information about the apps-samp mailing list