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

[Hugh Kelliher]

John,

Forgive me if I sound confused but don't Goddard want an SLE API for a
Solaris system? Or is that just the SOHO mission?

Why do ST-5 want to start from scratch? If they can't use the JPL API, do
they know about the Windows version of the ESA/Anite SLE API?

Best regards,

Hugh

----- Original Message ----- 
From: "John Pietras" <pietras@gst.com>
To: "'Michael Stoloff'" <Michael.J.Stoloff@jpl.nasa.gov>
Cc: <css-dts@mailman.ccsds.org>
Sent: Friday, November 07, 2003 4:08 PM
Subject: RE: [Css-dts] Put latest drafts of SLE API documentation on
docushare?


> 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
>
> _______________________________________________
> CSS-dts mailing list
> CSS-dts@mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/css-dts