> Hey Michael,
>
> I've been looking at that code recently. The company I work for is using
> the Slide client library to talk to Microsoft Exchange 2000 (mostly for
> address book and calendar functionality). The code you refer to below has
> been causing us some consternation, in that it doesn't seem to properly
> handle multiple namespaces in the same request - besides the fact that it
> doesn't properly separate name from namespace in all circumstances. I'd
> like to propose a solution to both problems at once.
>
> Determining what characters are or aren't legal in element names isn't the
> job of Slide - it's the job of an XML parser, and I think we should let a
> parser do that job. I propose that we augment your solution, below, with
a
> simple change. Instead of accepting an enumeration of strings
representing
> the element's namespace/name pair, the propfind could optionally accept an
> enumeration of objects each representing a property.
Actually, I had the same exact modification you describe done a few weeks
ago, but that's when my HD died :-(
I was checking the type of the object in the enumeration, and if it was a
Property, I was using that to retrieve the namespace URI and the local name.
Then another solution was proposed, and appeared to be working fine, so I
didn't bother writing that code again.
> If, for the sake of argument, propfind checked the type of the objects in
> the enumeration it's passed, it could handle Property objects specially.
> The org.apache.webdav.lib.Property interface, as you know, contains
separate
> fields for namespace, name, and local name, so using Property obviates the
> need to do the parsing in the Slide library. The old-style enumeration of
> strings would still be supported for backwards compatibility.
>
> This solution wouldn't require a change in PropFindMethod's public
> interface.
>
> I'm totally open to other solutions as well. I just wanted to get the
ball
> rolling...
Remy
