[cddlm] API issue: file upload

[Steve Loughran]

As stuart points out, the requirements for the deployment API says

"Upload of the files to the remote system will be supported."

What are we going to do about this?

1. What is the status on the repository proposal that was part of the 
BizGrid work?

2. Is there anything else we should look at.

I dont want to tack on file upload into the deployment API at this 
point. Its not just because of interop issues (you need to decide which 
of the many SOAP attachment extensions to mandate), but because I am not 
sure that sending up a binary file with a deployment is always the right 
thing to do.


We could do it so that when you deploy something, you can
-send up multiple binary attachments with the create request
-give each of these a URI
-use these URIs when referring to things in the deployment descriptor.

So you could deploy (server descriptor, ((myapp.ear,"uri:isbn:0012345")) 
and include references to the EAR file in the descriptor by URI

But what if you want to deploy something big, like jboss with postgres 
SQL server? And want different platforms to install a different version 
of postgres depending on their underlying CPU/OS? You would not want to 
upload everything in every single request. Instead you'd talk to a 
repository, upload the apps, upload any datasets you wanted, then send 
different deployment descriptors referring to the various pieces by URIs 
returned by the repository. Having it on the repository lets you 
undeploy and redeploy rapidly, without having to reattach the binaries. 
Also, if delegating deployment to something else, you can either include 
existing URLs to the data (assuming the repository is jointly visible), 
or copy needed binaries to a repository closer to the system.

note that the URLs used in descriptors do not have to be http:. All they 
have to be is urls that can be processed by the local deployment 
framework. This implies http:. file: (and shared filesys, which is 
trouble in its own right), or something else. As an example of the 
something else, look at the transit project: 
http://www.dpml.net/products/transit/index.html

with transit, you publish your artifacts to a repository as 
(name,version). You construct URLs to the artifacts using a new URL 
scheme, artifact: (transit has a plugin for Java  to do this), and then 
you refer to artifacts using "artifact:name#version". So if my code 
deployed on jboss4.0.3, the URL would be artifact:jboss-core#4.0.3  It 
is up to transit to locate the artifact, download it, cache it and then 
hand it off to the repository. Caching is part of the system: this makes 
the service more resilent to transient failures of repository access 
-indeed, more resilent than shared file systems often are.

Clearly we dont want to add repositories to our charter, but we want to 
work with them. Maybe we could do this by
1. enabling binary-with-deployment operations if that is what you want
2. encouraging the use of repositories

Comments?

-steve