[Patch] Webdav properties in UDSAtoms
Best, Jan-Pascal van
j.p.vanbest at tbm.tudelft.nl
Fri May 31 13:23:36 BST 2002
> On Thu, 30 May 2002 20:43, Best, Jan-Pascal van wrote:
> > > 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.
> >
> > Not too sure about that: when syncing a calendar to an
> exchange server,
> > we might have to do so for every appointment in the store.
>
> I see... any ideas how much that typically is?
Hundreds, or thousands of appointments? But it may not be so bad,
because after the first sync we can maybe check for the "lastmodified"
date.
> > Which brings
> > me to something else: the current webdav stat method seems to send a
> > PROPFIND to the server, with no further arguments.
> Shouldn't it contain
> > a message body like
> > <?xml version="1.0" encoding="utf-8" ?>
> > <D:propfind xmlns:D="DAV:">
> > <D:allprop/>
> > </D:propfind>
> > as per example 8.1.2 from RFC2518? This would also open the door
> > for YAM (yet another metadata ;) to instruct HTTPProtocol to
> > query for just a selected number of arguments, instead of all
> > arguments. The default might even be to query for just the arguments
> > that are used in davParsePropstats. What do you think?
>
> I think you are onto something... I have to do a similar
> thing to fix a bug
> with servers who don't like our not sending a content-length:
> 0 anyway. I'll
> switch it to only asking for the required data.
>
> In fact, here's an idea: the davRequestResponse should
> contain the request
> XML, or if blank, we will send <allprop/>.
Sounds good to me.
> The only thing to consider now is: when we are not requesting
> <allprop/>,
> should the additional propfind request be sent as a separate
> request? Or
> maybe as two <prop> blocks in the same <propfind>, if that works?
Sorry,, you lost me there. If we are not requesting <allprop/>,
we only request what's in davRequestResponse, so what additional
propfind request is there?
Cheers,
Jan-Pascal
More information about the kfm-devel
mailing list