[Pgi-wg] PGI Execution Service teleconference today Wednesday 06 May 2009 at 16h CEST

[Andrew Grimshaw]

All,
I propose that we not call it PGI Execution Service - that implies that we
are defining a specification, whereas I believe we can do this with a
profile and requests to change one or perhaps two other specifications
(BES).

> So, I advise that we agree on the largest possible list of states and
> transitions, with the semantics of their transitions.
> -  That will define PGI-compliance.
> -  Any further refinement of states will be accepted ONLY for logging
> purposes, but any further transition will be completely optional and NOT
> supported by PGI.
>
Agreed - we profile state extensions.
> A software service can easily publish the list of its states and the
> authorized transitions between states.  A software client can easily
> read them.

We won't need to do this if we profile the ones we want explicitly supported
and the service makes a conformance (to the profile) claim.

Also with respect to (w.r.t.) the logging bit. What a service does
internally with sub-states is its business. If it wants to use knowledge of
them somehow that seems fine to me.

A

> -----Original Message-----
> From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
> Etienne URBAH
> Sent: Wednesday, May 06, 2009 7:01 AM
> To: moreno.marzolla at pd.infn.it; pgi-wg at ogf.org
> Cc: edges-na3 at mail.edges-grid.eu; lodygens at lal.in2p3.fr
> Subject: Re: [Pgi-wg] PGI Execution Service teleconference today Wednesday
> 06 May 2009 at 16h CEST
> 
> Moreno and All,
> 
> Concerning the next PGI Execution Service teleconference held today,
> Wednesday 06 May 2009 at 16h CEST :
> 
> 
> New title of the GES document
> -----------------------------
> I propose 'PGI Execution Service'.
> 
> 
> States and Transitions Model
> ----------------------------
> A software service can easily publish the list of its states and the
> authorized transitions between states.  A software client can easily
> read them.
> 
> But beyond the syntax, the transitions contain SEMANTICS :
> -  Human software engineers can describe (with some work and review)
> these semantics for understanding by human software engineers,
> -  But I am afraid that it is very difficult to describe these semantics
> for understanding by a computer software.  Therefore, I am afraid that a
> software client can NOT guess how to adequately USE the listed
> authorized transitions.
> 
> So, I advise that we agree on the largest possible list of states and
> transitions, with the semantics of their transitions.
> -  That will define PGI-compliance.
> -  Any further refinement of states will be accepted ONLY for logging
> purposes, but any further transition will be completely optional and NOT
> supported by PGI.
> 
> Please study this issue, make your own mind, and express your position.
> 
> 
> Best regards.
> 
> -----------------------------------------------------
> Etienne URBAH         LAL, Univ Paris-Sud, IN2P3/CNRS
>                        Bat 200   91898 ORSAY    France
> Tel: +33 1 64 46 84 87      Skype: etienne.urbah
> Mob: +33 6 22 30 53 27      mailto:urbah at lal.in2p3.fr
> -----------------------------------------------------
> 
> 
> On Tue, 05 May 2009, Moreno Marzolla wrote:
> > Dear all,
> >
> > the next PGI teleconference will be held tomorrow, wednesday may 6th
> > at 16:00 CET (duration: 1 hour).
> >
> > Call-in details as follow:
> > via Skype call +9900827049931906 (free of charge) ordinary phone numbers
> > (local rates) with the 9931906 conference number:
> >
> > Austria 0820 401 15470
> > Belgium 0703 57 134
> > France 0826 109 071
> > Germany +49 (0) 180 500 9527
> > Switzerland 0848 560 397
> >
> > Agenda (please feel free to suggest additional items):
> >
> > 1) Whether http://forge.ogf.org/sf/go/doc15615?nav=1 contains
> > information which should be included in the requirements documents, as
> > suggested by Etienne;
> >
> > 2) Any final issues with the requirements document, especially with the
> > state model as discussed last time; hopefully this item will be
> > discussed very quickly;
> >
> > 3) How the requirements can be mapped into an actual implementation
> >
> > Moreno.
> >