[Moims-dai] Reminder of Skype call tomorrow (Tuesday)

[david at giaretta.org]

Meeting: 10:00 Tuesday (Washington DC time), 1500 UK time, 1600 Paris time.

 

If you do not receive a notification from Skype then please join it by
clicking the link:

 <https://join.skype.com/ykyu5SIPhSnD> https://join.skype.com/ykyu5SIPhSnD

 

*Don't have Skype yet? Download it before you join  <https://www.skype.com>
https://www.skype.com

 

Draft agenda:

1.	Project plan updates for CWE
2.	OAIS-IF - NOTE that Steve is having some days off so he may not be
able to make the meeting

a.	Details from last week: 

                                                               i.
Interactions - from Steve -
https://www.dropbox.com/s/dnftuks5nvixdl0/Interactions_210608.jpg?dl=0

                                                             ii.
Detailed suggestions from Mike -
https://www.dropbox.com/s/aw8yra2cpnd3op1/Draft%20Interaction%20Patterns%20f
or%20discussion-MK-20210608.pptx?dl=0

I (David) took an action last week to try to re-draw Mike's PPT to fit in
with the GB. However the basic incompatibilities made this pretty well
impossible.

Yet there were many good ideas in Mike's diagrams and they made me re-think
the sequence diagram that I put together quite a while ago.

A number of questions keep coming up:

*	How to consumers/archives/info sources discover how to talk to each
other?
*	What are the functions of an adapter?
*	Are there generic aspects to an adapter?

The new sequence diagram attached tries to provide some answers.

*	The adapters are tailored to the each end of the interactions
(InfoRequester and InfoSource), which have Adapter and Adapter2
respectively. These only need to be installed once
*	I propose a way for the adapters discover how to communicate with
the other side via, in this case, something I called a "switchboard".
"Switchboard" knows that Adapter2 can use say, HTTP (port 80 or 6789), or
CORBA or.. This allows Adapter to find out how to talk to Adapter2. 

NOTE that I am not talking about searching for objects. The assumption is
that somehow - not specified here - the InfoRequester discovers that it may
be able to get some info it wants from InfoSource.

*	The sequence diagram shows some interactions. Some of these are
specific e.g. "checkUsability()", which is closely tied to the design of
InfoRequester. On the other hand there are aspects which could be pretty
generic such as "requestPackage" and "requestRepInfoIDs". Another generic
part is knowing how to contact the "Switchboard" and initiate the
communications.
*	It seems to me that with a bit more analysis we could made some
clear interfaces between the specific part of the adapter and some generic
parts of the adapter. This would make implementations much easier.

                                                           iii.      WHITE
BOOK FROM Steve -
https://www.dropbox.com/s/fdd8ec5cq2y574z/02_White_Book_Recommended_Standard
_OAIS-IF_Draft_191216%20v5.3%2006_ComparedCombined_04_05_210524.docx?dl=0

                                                           iv.
Component diagram from Steve -
https://www.dropbox.com/s/5fsdmfcchzcqpz5/Component_Diagram_210601.jpg?dl=0

b.	Steve may sent out updated document/diagram
c.	The last version of the draft GB is
https://www.dropbox.com/s/k7s1s7xh9tt01wt/OAIS-IF%20Rationale%20Scenarios%20
and%20Requirements-20210516.docx?dl=0 - this includes my thoughts on
sequence diagrams, messages, etc.

 

Regards

 

..David

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20210621/3891f424/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SequenceDiagram-with-adapters.jpg
Type: image/jpeg
Size: 101264 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20210621/3891f424/attachment-0001.jpg>