[cddlm] In preparation for the CDDLM/ACS joint session at GGF14

[Keisuke Fukui]

Steve,

I snipped a part.

Steve Loughran wrote:
> 
> As long as references to content can be supplied as URLS, urls that the 
> programs/JVMs on the hosts can resolve, then we could do (2) and (3) 
> without a CDDLM implementation needing to know about how those URLs are 
> supported. That does imply HTTP/FTP/File, but since both .NET and Java 
> have a way of letting you plug in new URL handlers. If you had a new 
> url, something like
> 
> acs://app/124/component/12
> 
> then we could handle it, though I would strongly advocate using HTTP as 
> way of retrieving things. not only do all apps support it out the box, 
> it is easier to debug in a web browser

Does this mean the HTTP is your first recommendation for the component
to pull the files?

> 
> There are two more use cases,
> 
> -your asset store is used as the back end by an implementation of the 
> CDDLM services. That is, someone uses <addFile> to add a file, and the 
> request is forwarded to the ACS repository to add a new file to the 
> application. Would that work?

I think it's among the doable possibilities.
We however understood <addFile> is descried as an interim solution which can
be not used if an external asset store is used. The asset store can have
its own repository interface other than <addFile>.

Your point is to keep <addFile> in common among the implementations and the
components use HTTP to pull the things from there. So you expect external
repositories implement <addFile> as an native interface.
Is this correct understanding?

> 
> -the results of a job are somehow placed into the asset store, for later 
> retrieval by the submitter. This is out the scope of CDDLM; whatever you 
> deploy needs to handle that submission process.

We have discussed about storing the "output" of the job, but that is
pending, since the output can be variable per execution. I personally
doubt if this is sufficiently persistant or stable information that worth
stored in the repository.

> 
> Asset stores are a trouble spot with me in the past; they have caused 
> inordinate amounts of problems, at least when you are trying to use one 
> built on MSSQL and classic IIS/ASP. Here are some things that I recall 
> being troublesome
>  -many file systems cannot have > 65535 files in a single dir, so you 
> had better not use too flat a filesystem
>  -if the NAS filestore is set to the GMT tz and the server in PST, it 
> doesnt make any difference whether or not the clocks themselves are 
> syncrhonized; the auto-cleanup process is going to delete new files 
> under the assumption that they are out of date.
>  -its very hard to secure stuff
>  -any HTTP data provider must support HTTP/1.1 or at least 
> content-length headers, so that the caller can determine that the 
> supplied content was incomplete
> 
> As with most things, everything worked in development, it is only when 
> you go to production, put the asset store 1200km away from the rendering 
> service and keep the files on a different host from the database that 
> things start to go wrong.

Let us think about http a little more.

I'm looking forward to see you at our joint session.

  -Keisuke