perfsonar development work

["Jeff W. Boote" <>]

Hi All,

Jason and I have worked on a proposal for the document framework. Jason is going 
to add some information on this to:

http://wiki.perfsonar.net/jra1-wiki/index.php/PS_meeting_topics_proposals

The general idea is that documents will be in three categories:

Schema, Protocol, Service,

Schema:
        OGF Base Schema document
        A more specific extensions document that will specifically discuss
         how to extend the base schema. (with references to rnc files)
        Profile documents that document specific extensions to the schema
                - essentially eventType or new namespace based docs
                  Used to support each new data type or measurement type
                - each 'parameter' that is valid for a given eventType should
                  be documented for example.

Protocol:
        Base perfSONAR protocol
                Expected message sequence for the general protocol with 
specific
                information on Auth protocol, Echo Request/Response, and
                anything else that 'all' perfSONAR services MUST implement

        pS-protocol extension docs
                One per 'type' of interaction. For example, the MA/MP
                interactions are used across multiple services. This
                'pattern' should be a single 'extension' protocol.

Service:
        Individual service documents. They should include:
                * References to the specific pS-protocol extensions they
                  implement. (The MA/MP pattern for example)
                * References to the specific schema profiles they serve.
                  (utilization,errors,drops for example)
                * Service specific information - implementation details such 
as:
                  - architecture/design documentation
                  - installation/deployment documentation
                  - performance tips

One main objective here is to pull the portions of things that need specific 
agreement in the community (schema and protocol) away from the things that are 
service specific and need no agreement.

Another objective is to actually get specific agreement on protocols. Currently, 
several of the services implement identical or at least very similar 
functionality in different ways. (For example, the EchoRequest/EchoResponse 
messages should be understandable in all services - that is not to say type have 
to be identical, but they do need to be extended in an understood way. For 
instance, we can use additional eventTypes and different metadata inside to 
indicate different types of state. But, the base message types should be 
understandable by any/all services and clients in the same way. This is not 
currently true.)

Another objective is to make it more modular so that new versions of services 
can easily reference the protocol and schema information that they need to and 
update them to support multiple protocols/data types without having to go to a 
large amount of effort.

Jason plans to have some example documents and templates ready in time for the 
Zagreb meeting, and I will be at the meeting to more fully explain our ideas.

If there is agreement, what I would hope is that we could come up with the 
specific documents that need to be written (especially the ones where agreement 
is required) and come up with specific individuals with responsibility to finish 
them.

Thanks,
jeff


Nicolas Simar wrote:
> Jeff W. Boote wrote:
> > Hi Nicolas,
> >
> > I think this is a good step forward. All the pieces are there. My 
> > major concern is with some of the organization. I think too much is 
> > devoted to schema (rnc) concerns, and not enough to protocol. 
>
> It wasn't intentional if it appear as it is.
> Suggestion/proposal is welcome to modify it.
>
> I foresaw two roles for that document:
> 1) catch the information requirements from the developers
> 2) get a global overview of the document that are needed and what 
> already exist.
>
> The next step is to match those requirement against Jason's protocol 
> document proposal.
>
> > And, the lines between base/extension/service information is not so 
> > clear in many cases. I think it will take some real work to make this 
> > clear.
> >
> > This would probably be a good topic for the next full pS developers 
> > meeting (whenever that will be).
> >
> > [I apologize for not having time to give more substantive suggestions 
> > right now. Jason and I were just talking. Perhaps we can make a more 
> > substantial contribution to defining this after our MDM releases are 
> > ready?]
>
> I think getting a pointer to a protocol document from Jason would be a 
> good starting point.
>
> Cheers,
> Nicolas
>
> > Thanks,
> > jeff
> >
> > Nicolas Simar wrote:
> >
> > > Hi,
> > >
> > > you can find in attachment a document which identifies the different 
> > > documents that one can need.
> > >
> > > The goal of this document is to provide a “framework” of documents 
> > > (specifications, documentation) for perfSONAR and to identify the 
> > > information required so that we can have a stable 
> > > documentation/specification documentation structure.
> > >
> > > The document aims at identifying
> > > 1.    the different technical documents (specifications) that the 
> > > developers needs to have to implement inter-actions between the 
> > > services.
> > > 2.    the documentation that are provided for each service (e.g. for 
> > > the GUI developers to inter-act with a particular implementation of a 
> > > message or protocol).
> > > 3.    the process involved (e.g. to extend a schema, etc)
> > >
> > > For each type of documents, a high level description of the document 
> > > content or the multiple document that need to be produced is provided.
> > >
> > >
> > > I do strongly encourage you to read the document and
> > > - comment it
> > > - add the information you think is necessary to be in a document
> > > - raise question and points regarding the content of the document or 
> > > their structuration of the documents.
> > >
> > > The document and your comment will be used for a dedicated session in 
> > > Rome.
> > >
> > > Thank you very much in advance.
> > >
> > > Best regards,