In the near future, if you have some suggestions, please don't hesitate... Thank you for your good and helpful speech.... ^^...
Sung-Gu ----- Original Message ----- From: "Jim Myers" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, October 05, 2002 5:39 AM Subject: Re: client WebdavResource getMethod(path, .... ) is public? > 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
