[Css-dts] Put latest drafts of SLE API documentation on
docushare?
Michael Stoloff
Michael.J.Stoloff@jpl.nasa.gov
Fri, 07 Nov 2003 10:20:18 -0800
Just out of curiosity, what platform is ST-5 targeting?
We should put together a complete list of known implementations. For
example, I know that Avtec Systems (Fairfax, VA, USA) has a Windows
version of the SLE API. Also, I believe that Anite has a version of the
SLE API that runs on OpenVMS.
--Regards,
Michael
At 05:20 PM 11/7/2003 +0000, Hugh Kelliher wrote:
>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