I'll second the opinion that WebdavResource seems to have a bit of a schizophrenic character. The ability to perform actions on other resources are one example. Another is that there are get/set methods for some properties, such as displayname, that reference local variables and make WebdavResource look like a proxy object for the remote resource, while one also has access to perform the DAV calls directly.
I'm probably missing the logic of this mixture (needed to map well to files/URLs/etc?) but it seems cleaner to me to have WebdavResource be a full proxy - hide all the XYZMethod calls behind get/set methods (potentially with way to combine changes and cache information - e.g. call set multiple times and then do a single proppatch to synch with the server), or go the other way and make WebdavResource simply a way to pass a DAV URL around in object form (i.e. no state beyond that required to access the URL). Jim PS. FYI - I'm involved in a project that has tried to wrapper WebdavResource to go towards a proxy object, e.g. "new ResourceProxy(String URL, InputStream content, Hashtable properties)" which then sets up the WebdavResource object and does putMethod() and proppatchMethod calls. This appears to have helped the developers incorporate webdav access into their applications (they prefer using the wrapper versus WebdavResource directly). Wrapping WebdavResource as is is not the right long term design, but it was convenient as an initial implementation. Further, since the proxy may make multiple webdav calls to satisfy a request, other clients could see inconsistent state on the server - something we can live with, but not a good general solution, The idea of a webdav transaction standard would make a proxy approach more robust - all of the changes needed to synch the local object with the server, which might involve several webdav calls, could be combined as a single transaction. ----- Original Message ----- From: "Sung-Gu" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, October 03, 2002 9:39 PM Subject: Re: client WebdavResource getMethod(path, .... ) is public? > > ----- Original Message ----- > From: "Michael Smith" <[EMAIL PROTECTED]> > > > > Sung-Gu wrote: > > > > > > How do you guys use them? as public really? > > > with the first argument of each methods.... > > > Is it ok to support for one WebdavResource object? --a > > > Maybe as protected accessor or is it useful to remain it as public? > > > What do you think of it? I hope to have any opinions... > > > > The various methods in WebdavResource that take a path as their first > > argument generally don't make any sense - a WebdavResource object is > > meant to represent a single webdav resource with a specific path - using > > it to access a different path entirely seems an abuse of the design. I'd > > be happy with removing it or making it private or protected. > > I think so... > Thank you for your comment... ;-) > > Sung-Gu > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
