Steve, # Let me re-send this since I forget the attachment:-) Thanks for your update on this. Considering your comments below, we discussed a WS interface utilizing the uri identification as you proposed. Please take a look at the attachment to this e-mail. This depicts how the ACS Repository Interface "GetContents()" can work with multiple protocols. It is very similar with the AddFile() as it returns an uri. In our interface, Register() that pushes files into the repository returns EPR to the entry, then the GetContents() with protocol and keys to the subpart of the archive entry selects what and how the files can be retrieved from the repository. It will allow the http to be used among the other protocols supported by the implementation of the repository. Do you think this work for your use case? -Keisuke Steve Loughran wrote:
if you are deploying to a fabric with a shared filesystem, my preference is for file://, because any client that looks for file: urls will know it wont need to download and cache stuff.
otherwise, HTTP is good because (a) most things know about it (b) it is easy to debug behaviour by hand just by constructing the URL and tapping it in to your browser. (c) it goes through firewalls for remote download.