[Moims-dai] Telecon follow-ups
kearneysolutions at gmail.com
kearneysolutions at gmail.com
Tue Jan 5 17:31:57 UTC 2021
A few acknowledgements below.
-=- Mike
Mike Kearney
Huntsville, Alabama, USA
From: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org> On Behalf Of
david at giaretta.org
Sent: Tuesday, January 5, 2021 11:28 AM
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org>
Subject: Re: [Moims-dai] Telecon follow-ups
Hi Mike
See below for my 2p
..David
From: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org
<mailto:moims-dai-bounces at mailman.ccsds.org> > On Behalf Of
kearneysolutions at gmail.com <mailto:kearneysolutions at gmail.com>
Sent: 05 January 2021 16:38
To: 'MOIMS-Data Archive Interoperability' <moims-dai at mailman.ccsds.org
<mailto:moims-dai at mailman.ccsds.org> >
Subject: [Moims-dai] Telecon follow-ups
Here are two things that I couldn't get across during our telecon, but I'll
forget them before next week (actually before 5 minutes) unless I write them
down.
(1) Does "Null" mean the archive responds with:
a. A statement: "Sorry, I don't have that data that you requested"
formed as an information package with the information of that statement?
b. A statement: "Sorry, I don't have that data that you requested"
but NOT formed as an information package?
c. No statement. Something called "Null" which is non-responsive, but
not even a fully-formed statement?
d. Any of the above?
When I used the term it was in the programming sense that an API might
return "NULL", which is implemented in different ways in different
programming languages, but whatever language it is will recognise it as
"NULL". The common interpretation would be "I cannot give you this" perhaps
because I do not have it, or maybe I am not allowed or maybe there has been
an error - in the latter case in many programming languages one can get a
more detailed explanation e.g. "the network dropped out".
[MK] OK. I was trying to frame "Null" in the way that Steve could use it
interchangeably with an "Information Package". Sounds like that's not
feasible.
(2) In the discussion about whether the AIP is "visible" at the
interface, David proposed the scenario where an archive is transferring its
contents to another archive, and he proposed that they might request
"complete AIPs" as part of that transaction. Previously we discussed
whether we should specifically show archive-to-archive transactions, but we
concluded that we could meet the needs of the external archive simply using
the producer and consumer interfaces, so no special
"external-archive-specific" interface was needed for any given archive.
With David's scenario where an archive might request a complete AIP
containing object data and RI, does that mean we need to show
archive-specific calls? And therefore, Steve's UML should show
archive-to-archive transactions, and an external box called an external
archive (different from a producer or consumer)?
If on the other hand, the "complete AIPs" request might apply to consumers
also, then we don't need to specially show archive-to-archive transactions.
But in that case, in the green book, we should probably expand on how such
archive-to-archive transactions use the producer and consumer interfaces.
To my mind anyone could request the "full AIP" contents. In the draft Green
Book I just showed this in the OAIS to OAIS interaction because it was
convenient to link to the OAIS Preservation Strategies i.e. "hand over the
AIPs to another Archive", which was one of the things Vint Cerf mentioned as
necessary I believe, and also something we inserted explicitly in OAIS v3 -
no need to repeat all over the place because the idea is to be able to
define the APIs that everyone could use. In other words it will make our
lives easier if we avoid, as far as possible, having a different API for
each of Producer/Consumer/Archive/archive
[MK] OK, then based on that, no need for a specific archive-to-archive
interface. Thanks.
We can discuss these either by email or at the next telecon.
-=- Mike
Mike Kearney
Huntsville, Alabama, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20210105/64fc6db8/attachment.htm>
More information about the MOIMS-DAI
mailing list