Hi Chris,

This summary is my quick and thus not-well-informed look, so please
take this with some caveats (and corrections / comments by others are
welcomed):

1. The ims-url setting appears, from reading comments on CSPACE-4014
   and CSPACE-4051 (particularly Chris Martin's), to be primarily or
   exclusively relevant to constructing image URLs to be sent from
   Application->UI layers, for use by the UI layer in generating HTML
   image tags.

This is borne out by Chris's comment on the Talk list on 2011-05-27:

Here is the URL in a sample <img src="..."> tag for a medium-sized
media thumbnail on a Media Handling page on qa.collectionspace.org,
which points to an Application layer URL to retrieve that image:

http://qa.collectionspace.org:8180/collectionspace/tenant/core/download/923fd34c-c5d2-4d0f-bafb/Medium

Note: there is an unresolved JIRA for allowing the UI to directly
retrieve resources, including digital media, from the Services layer,
bypassing the Application layer:

http://issues.collectionspace.org/browse/CSPACE-4248

2. If BlobRead.get_blob is in fact the relevant, active method in
   the Application layer for retrieving media, its calls to retrieve
   binary "blobs," including digital media, are in turn sending requests
   to the Services layer's Blob service, at a specific URL path:

      private void get_blob(Storage s,UIRequest q,String

csid,String derivative) throws UIException {
try {
JSONObject out =
s.retrieveJSON("/blobs/"+csid+"/"+derivative,null);
...

This implies that it's the Services' Blob service that independently
determines the source(s) from which digital media might be obtained:
whether via local filesystem storage (Nuxeo-mediated or otherwise),
Nuxeo-based or external DAMs, or some other persistence.

The App layer's ims-url setting appears to have no involvement with
that; the value of that setting, at present, simply needs to be set to
the hostname or IP address of the host on which the App layer is
running, since the UI will always (at least until CSPACE-4248 is
resolved) be contacting the App layer to retrieve digital media.

Aron

On Tue, Feb 26, 2013 at 10:14 AM, Christopher Pott
Christopher.Pott@smk.dk wrote:

Thanks Aron for this great information, I guess we'd have to add to the Blob Service to deal with a new media storage interface. I was thinking we could simply configure a remote instance of Nuxeo dedicated to binaries but I can see now that this isn't what the <ims-url> tag is for.

In trying to understand the current media storage, I found that images saved in Collectionspace are stored on the local file system along a path which is built around the computed digest of the binary (starting at "$CSPACE_JEESERVER_HOME/nuxeo-server/binaries/data/"). For anyone else who didn't know this, I found the following page really useful in understanding how Nuxeo references these paths, including paths to the derivative versions of the files http://answers.nuxeo.com/questions/2761/thumbnail-paths .

Cheers,
Chris

-----Oprindelig meddelelse-----
Fra: aronroberts@gmail.com [mailto:aronroberts@gmail.com] På vegne af Aron Roberts
Sendt: 26. februar 2013 21:05
Til: Christopher Pott
Cc: talk@lists.collectionspace.org
Emne: Re: [Talk] storing media remotely

Hi Chris,

This summary is my quick and thus not-well-informed look, so please
take this with some caveats (and corrections / comments by others are
welcomed):

1. The ims-url setting appears, from reading comments on CSPACE-4014
   and CSPACE-4051 (particularly Chris Martin's), to be primarily or
   exclusively relevant to constructing image URLs to be sent from
   Application->UI layers, for use by the UI layer in generating HTML
   image tags.

This is borne out by Chris's comment on the Talk list on 2011-05-27:

Here is the URL in a sample <img src="..."> tag for a medium-sized
media thumbnail on a Media Handling page on qa.collectionspace.org,
which points to an Application layer URL to retrieve that image:

http://qa.collectionspace.org:8180/collectionspace/tenant/core/download/923fd34c-c5d2-4d0f-bafb/Medium

Note: there is an unresolved JIRA for allowing the UI to directly
retrieve resources, including digital media, from the Services layer,
bypassing the Application layer:

http://issues.collectionspace.org/browse/CSPACE-4248

2. If BlobRead.get_blob is in fact the relevant, active method in
   the Application layer for retrieving media, its calls to retrieve
   binary "blobs," including digital media, are in turn sending requests
   to the Services layer's Blob service, at a specific URL path:

      private void get_blob(Storage s,UIRequest q,String

csid,String derivative) throws UIException {
try {
JSONObject out =
s.retrieveJSON("/blobs/"+csid+"/"+derivative,null);
...

This implies that it's the Services' Blob service that independently
determines the source(s) from which digital media might be obtained:
whether via local filesystem storage (Nuxeo-mediated or otherwise),
Nuxeo-based or external DAMs, or some other persistence.

The App layer's ims-url setting appears to have no involvement with
that; the value of that setting, at present, simply needs to be set to
the hostname or IP address of the host on which the App layer is
running, since the UI will always (at least until CSPACE-4248 is
resolved) be contacting the App layer to retrieve digital media.

Aron

On Tue, Feb 26, 2013 at 10:14 AM, Christopher Pott
Christopher.Pott@smk.dk wrote: