On Mon, Feb 14, 2005 at 01:05:40PM -0500, Greg Hudson wrote:
> On Mon, 2005-02-14 at 11:51, Ben Collins-Sussman wrote:
> > 2. mod_dav_svn notices whether the incoming lock was created by
> > an svn client or a generic DAV client.
>
> I'd rather see us test whether the author field is minimal or not. If
> it looks like <D:author>blah</D:author>, it would be nice to unpackage
> it regardless of whether the client is a generic DAV client. My theory
> is that most DAV clients will send a minimal author spec, and it would
> be nice not to display their lock fields as junk to non-dav clients.
Agreed. This is/was the original solution that Ben and I worked thru via
AIM. We came up with an idea to detect "minimal" and do the stripping.
I think the current problem is that if you're looking at a lock->comment,
then how does mod_dav_svn determine whether it was stripped (and needs
wrapping), or should be passed along unchanged?
A simple detection rule might be, "is the first character '<' ?" But what
if a comment can legitimately contain that? Then you could end up a
DAV:owner tag wrapped around some content that it shouldn't have wrapped.
> On another note, if the author field is using namespace tags which were
> defined elsewhere, how can we be sure those namespace tags are defined
> the same way in the response? How does the DAV spec address this
> problem?
mod_dav passes a serialized XML fragment which is internally consistent
with the namespaces/prefixes. It was designed this way so that the result
could simply be dropped into the output XML stream without worrying about
a bunch of namespace crap (as you rightly were concerned about).
In any case, I think the question comes down to: is there a detection rule
that is workable for "should this be wrapped?" A heuristic is available;
is that good enough? If not, then a boolean as Ben suggests is a good way
out of the problem.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 14 21:07:27 2005