[Moims-dai] Draft proposals: Future work and CMC pitch

Fri Jul 8 21:05:23 UTC 2016

Meant to also address Don’s suggestion:  

*  My approach would be to divide up the ‘data space’ much as shown in your diagram, and then have one or two people develop a starting set of services for each space.  

That’s exactly what SM&C did.  Those bindings in the “messaging layer” were done by agencies, where each had a special interest.  For example, ESA did a binding to PUS (Packet Utilization Standard).  NASA JSC did a binding to TCP/IP.  

Like any CCSDS project the funding/resource issues will dominate the list of obstacles.  SM&C had a lot of trouble getting agencies to develop specific bindings and then prototype them.  But over the years they have developed a suite of services at that bottom layer.  In the future utopian archive world, agencies and organizations with the interest would pick them up.  In the long run, if this gains critical mass, I’ll bet a presentation at the IIPC would find a number of volunteer organizations willing to develop the web/HTML binding specification and prototyped plug-in.  

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

From: Mike Kearney [mailto:kearneysolutions at gmail.com] 
Sent: Friday, July 8, 2016 3:58 PM
To: 'MOIMS-Data Archive Ingestion' <moims-dai at mailman.ccsds.org>
Subject: RE: [Moims-dai] Draft proposals: Future work and CMC pitch

*  Do we know if anyone has tried generating a broadly applicable abstraction for general data?

Well, one that is very close at hand is the Message Abstraction Layer that has been developed by the SM&C working group and implemented by several agencies.  It handles exchange of messages from above and below, and the “below” interfaces are a multitude of bindings to various network and link transport technologies.  Hence my analogy to a multitude of bindings to unique archives for various disciplines.  And they deal heavily with registries at each interface, so I think it’s not a large leap to deal with archive metadata.  

Here’s the diagram from their framework book.  Notice the common consumer/provider terminology.  

Exactly how broadly applicable it is for general data would be something to explore.  But I thought it would be best to hold off on those discussions with SM&C until we fully discussed it within DAI.   It certainly is broadly applicable for putting any data type into a messaging/transport interface, which might be a good indication that it’s pretty broad.

In that bottom “messaging technology” layer are bindings for TCP/IP, DTN, various link layer comm technologies, etc.

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

-----Original Message-----
From: Moims-dai [mailto:moims-dai-bounces at mailman.ccsds.org] On Behalf Of D or C Sawyer
Sent: Friday, July 8, 2016 3:34 PM
To: MOIMS DAI List <moims-dai at mailman.ccsds.org <mailto:moims-dai at mailman.ccsds.org> >
Subject: Re: [Moims-dai] Draft proposals: Future work and CMC pitch

All,

Since it is unlikely I’ll make the next Telecon (heading to Canada), I thought I’d offer a perspective or two on the slide showing a possible abstract data layer. Unlike with various targeted communication protocols dealing with spacecraft, the scope of the existing data services is much more diverse in my opinion.  That said, it would be an interesting challenge to explore.  My approach would be to divide up the ‘data space’ much as shown in your diagram, and then have one or two people develop a starting set of services for each space.  Then do an investigation of the actual services in whatever scope of applicability (all communities, only certain disciplines, etc.) was set for the abstract layer in order to not miss any that are important.

Do we know if  anyone has tried generating a broadly applicable abstraction for general data?

Cheers-

Don

On Jul 8, 2016, at 12:11 PM, Mike Kearney < <mailto:kearneysolutions at gmail.com> kearneysolutions at gmail.com> wrote:

> Sorry if this seems totally out-of-the-blue, but we’ve talked around these topics, and I decided to try to put my thoughts on paper (or PPT anyhow).

>  

> This starts with a DAI discussion about future work in protocols/APIs, Architecture, and then branches off to a presentation for the CCSDS CMC on that topic and a few other topics.   I figured the best way to describe where I suggest we go is to put it in words advocating it to management. 

>  

> This in no way tries to derail the current work.  If you look at the proposed (very drafty) schedule, this new work kicks in after the current project and the OAIS revision is over.   I think.  

>  

> So, I’d like to discuss this at an upcoming DAI telecon.  There’s no rush on this, so if there are other topics for next Tuesday, it can be later. 

>  

> Thanks, 

>  

>    -=- Mike

>  

> Mike Kearney

> Huntsville, Alabama, USA

>  

> <Discussion points for CMC concerns 7-8-2016.pptx>_______________________________________________

> Moims-dai mailing list

>  <mailto:Moims-dai at mailman.ccsds.org> Moims-dai at mailman.ccsds.org

>  <https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai

_______________________________________________

Moims-dai mailing list

 <mailto:Moims-dai at mailman.ccsds.org> Moims-dai at mailman.ccsds.org

 <https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20160708/53582eeb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 29246 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20160708/53582eeb/attachment.jpg>