[Css-dts] Put latest drafts of SLE API documentation on docushare?

[John Pietras]

Michael,
The specific project that sparked this request is ST-5, and your
assumption is correct that interoperability with the existing
implementations is the key driver. So your offer to put together the de
facto library is most welcome. Perhaps an "implementation version"
subdirectory of the public DTSWG docushare space would be the
appropriate repository, with correspondence directed to the SLE
implementers' mail list 
(sle-imp@mailman.ccsds.org). 

In this same vein, I talked yesterday with Tim Ray of GSFC. Tim will be
developing the CLTU implementation for ST-5. One of the problems that
will be facing Tim is that GSFC does not want to use Solaris, so an
off-the-shelf application of the JPL API is not possible. He would
prefer to do a clean, non-API-based implementation (although I think
that I made him realize that all other things being equal, using an
existing API code base is the faster way to go). I mentioned to him that
NASDA (JAXA) did a non-API implementation, but I know that they had to
rely on material in (I believe) the proxy specification to complete the
information needed. You and I discussed some time ago that you thought
that you could generate a wire protocol specification relatively easily.
Even if we don't try to develop a CCSDS standard for such a protocol, an
"implementation note" that contains such material would be beneficial in
those cases where the use of the API is infeasible or inappropriate. At
a minimum, any notes that NASDA can provide about their experience
should be placed in this repository also.

Best regards,
John

> -----Original Message-----
> From: css-dts-admin@mailman.ccsds.org [mailto:css-dts-
> admin@mailman.ccsds.org] On Behalf Of Michael Stoloff
> Sent: Wednesday, November 05, 2003 4:11 AM
> To: pietras@gst.com
> Cc: css-dts@mailman.ccsds.org
> Subject: Re: [Css-dts] Put latest drafts of SLE API documentation on
> docushare?
> 
> John,
> 
> The purpose of this message is to seek certain clarification with
respect
> to your request.  The following background information may be relevant
in
> this context.
> 
> The DSN as an SLE service provider has inter-operated for actual
mission
> operations with ESA, ISAS (now JIXA), JHU/APL, and NASA/JPL SLE
service
> users.  Further, JPL flight projects have now inter-operated as SLE
> service
> users with an ESA SLE service provider.  Based on that collective
> experience, I believe that there is exactly one, de facto,
inter-operable,
> version 1, SLE services and protocols standard.  Moreover, I believe I
can
> identify a very specific set of documents (down to the specific
version of
> each document) that, taken together, constitute a complete and
accurate
> specification of what I am calling the de facto version 1 SLE
standard.
> 
> I am guessing that what the GSFC flight projects really want is to be
able
> to inter-operate on the same basis as the implementations I have
listed
> above.  If that is the case, then I suggest what they need is the
complete
> set of documents that I have in mind.
> 
> If that sounds about right to you, then I would be happy to work with
you
> and Wolfgang to put that complete set of documents together in one
> place.  (Note that there are a few minor complications with the
> documentation that would have to be addressed to complete the task,
but
> nothing that we shouldn't be able to resolve in relatively short
order.)
> 
> BTW, the set of documents that I have in mind does not include either
the
> RAF or CLTU Issue 1 Blue Books.  It does include versions of the RAF
and
> CLTU books, but the exact versions of those books that correspond to
the
> de
> facto version 1 SLE standard are not the published Blue Books.
> 
> This whole situation is, of course, somewhat unsatisfactory (though,
as
> things developed, I think it was the unavoidable price we paid in
order to
> get SLE off the ground at all).  There is a plan in work to get to a
point
> where the de facto standard and the official, published
Recommendations
> are
> fully consistent.  That plan is based on publishing Issue 2 Blue Books
and
> moving to a version 2 SLE standard.  The differences between the de
facto
> version 1 standard and the de jure / de factor version 2 standard
should
> be
> very minor, but there seems to be a consensus that those minor
> enhancements
> are in the best interest of SLE in the long run.  Once the version 2
> standard is fully documented and implemented, I believe both JPL and
ESA
> would intend to de-commit support for the version 1 standard after a
> suitable transition period.  In the spirit of full disclosure, those
> considerations should be explained to the GSFC flight projects.
> 
> Just my two cents worth.  Please let me know how you would like to
> proceed.
> 
> --Regards,
>    Michael
> 
> At 10:37 AM 11/4/2003 -0500, John Pietras wrote:
> >Members of the DTSWG:
> >I have had several inquiries from GSFC flight projects about the SLE
> >API. Part of what they ask for is documentation. I have versions of
the
> >Anite documentation and past draft White Books, but I am not certain
> >whether these constitute the latest information. Please consider
putting
> >the latest and/or most accurate API documentation in the private part
of
> >the DTSWG docushare archive, so that those of us who need to
reference
> >it can access the most "blessed" version.
> >
> >In the short term, can someone give me a suggestion for which
documents
> >I should provide (or point to) when asked?
> >
> >Thanks.
> >
> >Best regards,
> >John
> >
> >_______________________________________________
> >CSS-dts mailing list
> >CSS-dts@mailman.ccsds.org
> >http://mailman.ccsds.org/mailman/listinfo/css-dts
> 
> _______________________________________________
> CSS-dts mailing list
> CSS-dts@mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/css-dts