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