Edi et al.,
It seems like it would be pretty straightforward to move the cl-webdav- level-2 stuff into it's own asdf system.
There are a couple of things from my patch that should probably go into cl-webdav (and ht) as is, but most of it could easily moved to another package and still get the functionality we want.
The only tricky bits are the the handlers. How should we handle the bits that need to reach down into the existing propfind/get handlers? We could just redefine these with the copy/pasted/modified code in the new asdf system, but that seems like a hacky OAOO violation that is likely to lead to subtle bugs down the road. Some sort of CLOS hackery with around methods? A list of functions to call for each handler? Thoughts?
thanks,
Cyrus
On Sun, 29 Jun 2008 19:13:19 -0700, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
It seems like it would be pretty straightforward to move the cl-webdav-level-2 stuff into it's own asdf system.
FWIW, I personally think that the level 2 support is a valid addition and should eventually be part of cl-webdav itself.
Ok, that's good to hear. That brings up two points though:
1. should we leave my cxml-stp/xpath stuff in there are rewrite the xml bits to look more like the cxml code used elsewhere in cl-webdav? Obviously, I vote for leaving it as is, but that's mostly because I don't want to be bothered to rewrite this using straight cxml.
2. there may be other extensions to cl-webdav that don't belong in cl- webdav itself and the experience of trying to add locks may inform the API decisions regarding extensibility of cl-webdav. I'll answer the rest of this in the next message...
cyrus
On Jun 29, 2008, at 11:45 PM, Edi Weitz wrote:
On Sun, 29 Jun 2008 19:13:19 -0700, Cyrus Harmon <ch-tbnl@bobobeach.com
wrote:
It seems like it would be pretty straightforward to move the cl-webdav-level-2 stuff into it's own asdf system.
FWIW, I personally think that the level 2 support is a valid addition and should eventually be part of cl-webdav itself. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Sun, 29 Jun 2008 19:13:19 -0700, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
The only tricky bits are the the handlers. How should we handle the bits that need to reach down into the existing propfind/get handlers? We could just redefine these with the copy/pasted/modified code in the new asdf system, but that seems like a hacky OAOO violation that is likely to lead to subtle bugs down the road. Some sort of CLOS hackery with around methods? A list of functions to call for each handler? Thoughts?
OOAO? What does that mean?
Besides, if it is in a separate /system/, it doesn't have to be in a separate /package/, right?
On Jun 29, 2008, at 11:48 PM, Edi Weitz wrote:
On Sun, 29 Jun 2008 19:13:19 -0700, Cyrus Harmon <ch-tbnl@bobobeach.com
wrote:
The only tricky bits are the the handlers. How should we handle the bits that need to reach down into the existing propfind/get handlers? We could just redefine these with the copy/pasted/modified code in the new asdf system, but that seems like a hacky OAOO violation that is likely to lead to subtle bugs down the road. Some sort of CLOS hackery with around methods? A list of functions to call for each handler? Thoughts?
OOAO? What does that mean?
OOAO. Once and once only. Must be an sbcl-developerism. The idea is to avoid hacky duplicated code...
Besides, if it is in a separate /system/, it doesn't have to be in a separate /package/, right?
yes, it can be in the same package. nevertheless, the issue of how to extend the existing handlers still arises. I have been thinking about this a little bit. Perhaps my thoughts will be clearer in the morning.
-
Cyrus Harmon -
Edi Weitz