On Monday 08 April 2002 19:14, Dossy wrote: > Why DOM and not SAX? Is it really meaningful to hold the > entire WebDAV message in memory as a DOM tree? You really > only need to pick up a few things (which SAX would be > great for) then form a response -- this is where I might > use DOM to assemble the outgoing XML message.
Funny... I was thinking the exactly in the opposite direction :) Let me explain. The incoming DAV messages (from client to server) are very simple and short. To use (or not to use) DOM for them is IMHO of the academic importance. I prefer DOM for a simple reason of having all XPath support and other goodies, so I can find out what the client wants, easily. SAX is (again, this is my personal oppinion) simply to clumsy for that. Okay, these couple of tags are not complicated to analyze with SAX, I admit that. As I said, academic importance... OTOH, server response might be a place where this does not hold true, i.e. with "Depth: infinity" and with a large collection, XML response *may* become pretty large, in which case one might preffer to synthetize the output message on the channel directly, w/o having to build it in DOM tree in memory first. But, having said that, my experience with DOM shows that even in this case, provided you have a fast optimized DOM implementation, there is no big deal in generating 100's of K of XML in subsecond range in the DOM tree. > Perhaps this is a good place to start a new nsauth module to > which can replace nsperm. Leave nsperm in place (to not break > backward compatibility, etc.) but start fresh with a well-designed > nsauth. This is a good idea. > Could a short design discussion be in order? What are the concerns, > and the needs that must be addressed? I'd say people should tell what they miss/dislike from/in the current implementation. I can give my (2 cents) here... What I do *not* like is that the core server favorizes Basic authorization method all over the place. The C-API has no provision of adding another authorization type. The nsperm module is layered on top of that, but some other (than Basic) authorization module has really no hooks to attach to. The Apache has AuthType directive and you can hook whatever you like there. This is how mod_digest is implemented (or was it mod_auth_digest?). Admittently, very few from the browser arena actually support other than Basic authorization. But in the example of DAV, this is a MUST declared in the RFC. You have no choice... Having said that, one can quickly see that implementing Digest auth type for WebDAV can either be a quick shot for to_get_it_running, or a redesign of the servers C-API. Hmmmmm.... Zoran
