The 0.9 release I used is from March of this year. It is pre-sparse content. Some of the changes I made were submitted and incorporated into the code base (a small API change and corresponding search servlet change to allow properties for results sets to be passed back). Changes I have made since are a bit more fundamental, have been submitted.
Sakai3 UX talks to the Nakamura back end by http. These can be resources or service endpoints
Servlet resolution is magic; things like extensions do not filter, but rather contribute to a score. Servlet bindings are magically registered using annotation incantations. In this case, a servlet in the files bundle checks to see if the URL had the extension, and if so, it sends JSON. If not, the default servlet is used and just returns the bits.
You can access these resources directly by entering the sakai server URL and then /p/<jcr:name> For example, this is what you get by accessing http://sakaidc.mse.jhu.edu:8080/p/.......metadata.tidy.json Without the extensions, you get the bits.
This is similar to the last example, same idea, same extensions. Without the extensions, you get the contents of the file, which is just the external URL.
Not the same as just pointing out to a web resource. There may be access permissions involved, for example. Also, we will want to allow other methods like creating, updating and deleting. This requires more infrastructure. the docproxy bundle addresses this.
So there will be a service endpoint for searching against each repository type.
Search endpoint probably could also use the repository-type property instead of repository-ref (it would be more elegant) – this would require a small change in the search servlet The first two of these are placed in the source tree and are created when the instance is first fired up.
Have changed resourceType for metadata servlet
Trace through an example search ... hits the service endpoint (in our case, /var/search/docproxy/dcs.json) This request is resolved to the ExternalDocumentSearchServlet, which calls the search method in the processor. This returns an ExternalSerachResultSet of ExternalDocumentResults to the servlet, which in turn serializes this in JSON format. This is presented to the UX.
Our data model is derived from OAIS and PLANETS. Have Collections, DeliverableUnits, Manifestations, Files Most useful metadata for searching is in the Dus, so we search for them, give a list ... user selects an interesting one, then gets to see all the Files in there, can then import the files to sakai.
Create could be interesting, because we need to submit in a Submission Information Package (SIP) Will probably need a tool to do this.
Connecting to Remote Repositories: Implementing the Docproxy Interface in Sakai OAE Jim Martino, Software Engineer, Johns Hopkins University
Servlets We also have servlets to handle the new resource types. Servlet resolution will depend primarily on the resourceType and node path, with further refining from any extensions and selectors appended to the URL. These servlets then call the appropriate methods in the repository processors. 12th Sakai Conference – Los Angeles, California – June 14 - 16