[Patch] Webdav properties in UDSAtoms

[Hamish Rodda]

On Thu, 30 May 2002 19:34, Best, Jan-Pascal van wrote:
> My first idea was to add a "QDomElement m_xml" member field to UDSAtom,
> but I feel
> that might give too great a performance hit on all other systems and
> applications using
> UDSAtoms.

Probably, especially because you would have to duplicate the actual document 
(QDomElements rely on their parent QDomDocument for their data).

> My current implementation uses just another UDSAtomType,
>   UDS_WEBDAV_PROPERTIES = 32768 | UDS_STRING
> and then in http.c:HTTPProtocol:davParseProperties checks whether
> the metadata "davRequestResponse" is set to "true". In that case,
> it adds an UDSAtom to the current UDSEntry, of type
> UDS_WEBDAV_PROPERTIES, containing the <prop/> XML element string.

This looks good to me. It solves another problem I might have run into 
eventually, that of writing a good metainfo plugin, and extending to 
additional features such as direct source editing.

The only query I would have is whether this should be called something else in 
case another ioslave wants to use the same functionality; maybe 
UDS_XML_PROPERTIES?

> The main argument against this method is that we now first parse the
> servers response, then encode the properties as an XML string in the
> UDSAtom, and then (in the application side) parse the same data again!

If you ask me this isn't too much to ask of a computer these days, especially 
where it is only going to be doing so when special features are required 
anyway.

I take it you're dropping the idea of removing the restriction to the DAV: 
namespace from davParsePropstats? I recall that adhering to the namespace was 
necessary to avoid name conflicts I experienced while testing the ioslave.

Cheers,

Hamish.