|
Size: 2557
Comment:
|
Size: 2561
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| == First thoughts on choice of integration with Summa == | === First thoughts on choice of integration with Summa === |
| Line 19: | Line 19: |
| == Methods needed in Summa integration component, as an implementation of the Summa storage API == | === Methods needed in Summa integration component, as an implementation of the Summa storage API === |
Analysis of Task 31
First thoughts on choice of integration with Summa
There are three ways in which Summa can receive content for indexing (and presentation)
- By the DOMS side calling an ssh-script to deliver a zip file of contents to Summa
- By the Summa side requesting latest changed objects via OAI-PMH
- By the DOMS side implementing the Summa API, through which Summa can request latest changes
The last option appears to be the most convenient for our use. Reason: The first would require more development on our part than the last. And the second is less convenient for Summa than the last. So, the last it is.
Methods needed in Summa integration component, as an implementation of the Summa storage API
We need an implementation of Summa's ReadableStorage interface, that is, the following methods
- getModificationTime(String base)
getRecord(String id, QueryOptions options)
getRecords(List of Strings id, QueryOptions options)
getRecordsModifiedAfter(long time, String base, QueryOptions options)
- next(long iteratorKey)
- next(long iteratorKey, int maxRecords)
See Summa Storage API javadoc at (where?)
Sequence diagrams showing the surroundings of the Summa Integration component:
Prerequisites and Assumptions