I'm not Peter, but I think I can answer some of the questions: > 1. What is the difference between protocol-oriented and resource-oriented?
Protocol-oriented API allows you to handle deep detail of the protocol spec (HTTP/DAV/DeltaV/...) whereas resource-oriented API only allows you to see "abstracted away view" of the spec, say "files and collections". With latter API only, you won't be able to use full feature of base specification, like adding custom "If-Match:" header to detect race condition upon PUT operation. > 2. Where are javax.wvcm.* + org.apache.wvcm.* currently implemented > in the Slide client? I did not see them yet? (Sorry if they were > added recently, I a on a CVS from some weeks ago.) It's in CVS. I think it went in last month. See "proposal/" folder. I don't know how feature complete it is, but it can be build. > 3. What would be the benefit of building on javax.wvcm.* + > org.apache.wvcm.* rather than org.apache.webdav.lib.*. You can claim to be "Standard Compliant(tm)" :-) Just like DOM API in XML, once WVCM becomes standard, you should be able to make a switch to other implementation whenever needed. Considering maturity and availability of implementations (there's no point in standard unless you have multiple implementations to choose from), I think going with native Slide API is a safe bet for now. But be prepared for WVCM (and other) APIs... -- Taisuke Yamada <[EMAIL PROTECTED]> Internet Initiative Japan Inc., Technical Planning Division --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
