the webdav bits that we have in there are pretty simple, don't want to misrepresent that really :)
Basically how it works right now is the httpclient is registered with a webdav listener which when it sees that an http put request has failed with a certain response code it then takes over the execution and rewinds back looking for the lowest directory resources that exists and then starts issuing MKCOL requests to the server to make those resources. That is how the basic webdev goop works, its pretty chatty but seems to be required. Once it has been successful with the MKCOL's it will retry the original request to put the artifacts there. Oh, and it checks if webdav is enabled on the server before it tries to do much... So it will basically only take over when the server reports it is dav enabled and the request is a PUT and that fails it will see what it can do. I haven't tested against all the dav servers out there but the basics of it are very lightweight and easy to work with so if it starts having issues with anything dav out there it will be pretty easy to make work. which from mercury's perspective is pretty sweet, it uses the jetty client and says 'hey enable dav listening and if conditions are right to use it, try and do so' and that is the last it worries about dav cheers! jesse On Wed, Sep 17, 2008 at 2:10 PM, Oleg Gusakov <[EMAIL PROTECTED]> wrote: > Jason van Zyl wrote: >> >> I think you should explain some of the transport features as well. I know >> what you, Greg, Jan, and Jesse have done and it's significant and you should >> outline those. >> > Mercury transport layer is an absolute work of art done by Jetty folks. It's > a complete implementation of HTTP stack that sits on top of java nio > framework. Then they added transactional support for file transfer - > transport guarantees delivery of intact binary to or from a remote server. > Then they added observable up/down streams. Then these streams could be made > verifiable with stream verifier abstraction - checksums, crypto signatures. > As a result - client does not have to deal with these gory details - > transport layer takes care of that. > > One interesting optimization feature: a stream verifier could be declared > "sufficient", so if it verifies a stream, all other verifies are not even > asked any more. > > On the outside - transport supports two way transfer of files and in-memory > streams. [The latter are used in Mercury for pom and metadata processing: > unless passed through conflict resolution - these bytes never hit the disk.] > It accepts a request for multiple transfers and runs them in parallel, fully > utilizing throughput abilities of our machines and multiplexing nature of > nio. > > Now a story: this - caused an interesting problem in wagon implementation: > wagon APIs got rid of the good old pattern (byte [] buf, int off, int len) > and replaced it with (byte [] buf, int len) thus presuming that data always > starts at the beginning of a buffer. But jetty/nio optimizes buffer usage > and offset is actively used in all the interactions. To pass data to wagon > infrastructure - I had to create a new buffer and copy data to it's start, > somewhat loosing in efficiency [of cause - it would not be an issue in c] >> >> Nexus actually will accept a simple PUT, but it doesn't do WebDAV. We >> might put it back but it's just PUT. > > My bad - terminology. >> >> But we could setup a simple WebDAV server using Jetty and a WebDAV servlet >> to try it. You could probably snag the tests from the WebDAV wagon. I assume >> there are some Jetty+ > > Good point, will do. >> >> I would be interested in seeing a branch created with this as the default >> http provider. If it's a complete replacement for the >> lightweight/regular/webdav wagons then I think this would be a good thing. >> > I will grab the 2.1 trunk and do that > > Thanks, > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
