On Dec 29, 2009, at 4:43 PM, Markus Karg wrote:
> Paul,
>
> oops, seem's you're right. Strange that all currently tested WebDAV
> client's don't care about this.
I think it is one of those things utilized for browsing WebDAV using
say a file-based browser, like the MacOS Finder.
> On the other hand, the spec doesn't say that it must be the same
> value in both cases, just that the property must be provided: Since
> both operations could be interrupted by a second client modifying
> the length (as LOCKing is not mandatory in WebDAV), it wouldn't make
> sense anyways.
>
> BTW, just for anybody interested in it: Just finished performance
> tests with WebDAV ontop Jersey. Directly listing in Vista
> FileExplorer (1000 "files" taken from a embedded derby db using JPA
> via Jersey) on a dual core laptop needs just a quarter of a second.
> For comparison: The same machine needs several seconds to provide
> the same view using it's local physical NTFS. That's just gread. :-)
> Strange but true, using a single thread and storing the XML byte
> stream in RAM to later rewrite it is two times faster than using two
> threads working in parallel using Piped*Stream or
> BlockedLinkedList<ByteBuffer> -- Java's memory management seems to
> be lightning fast, compared to a Thread context change (even when
> using Executors.newChachedThreadPool)! Daniel worked hard on support
> for Windows 7, W2K3 and Office WebDAV clients, and I fixed Vista
> support. Seems all current Windows OSs work well and fast now. We'll
> release all fixes within 2009, so in 2010 people can have complete
> and performance optimized "file" API based access to their server
> side data. Looks like we'll have a big party on dec 31! :-D
>
Cool! Thanks for the anecdotal performance info, it is very useful to
hear that.
Paul.