[Patch] Webdav properties in UDSAtoms

[David Faure]

On Thursday 30 May 2002 11:34, Best, Jan-Pascal van wrote:
> Responding to myself again: Subclassing is no use, because UDSAtoms are
> sometimes
> streamed to and from QDataStreams. We have have modify the
> operator>>(QDataStream, UDSAtom) anyway.

And they are used as values (QValueList<UDSAtom>, created by slaveinterface IIRC,
not sure subclassing is possible).

> 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. 
Yes! And anyway, passing a dom element between processes means passing
the XML string - which is what you're doing now ;)

> 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.

Sounds good. I would even make this more generic, like
UDS_XML_PROPERTIES.
I suspect people will want to reuse this in other slaves in the future.

> From the application side, this means that you set the
> "davRequestResponse"
> metadata before a STAT, LIST or SEARCH. When examining the results, the
> webdav properties can be found in one of the UDSAtoms connected to the
> UDSEntry. 
> 
> 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!

How big is that XML string, typically?

Seems the parsing of the XML in kio_http is necessary anyway, and the app is
another process, it has to reparse it anyway. I don't think there's any other way,
that's part of the "separate process" design. But it shouldn't be a big problem.

> +      atom.m_uds = KIO::UDS_WEBDAV_PROPERTIES;
> +      QDomDocument doc;
> +      doc.appendChild(prop);
> +      atom.m_str = doc.toString();
> +      entry.append( atom );

Hmm, no way to get prop.toString()? Ok.

-- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KDE, Making The Future of Computing Available Today