Re: multiget reports Re: Thoughts on relation to WebDAV

On 29.05.2008, at 09:41, Stefan Eissing wrote:
> This BATCH/multi-GET topic comes up quite regularly every year or  
> so. It's a pony discussion.

I guessed so ...


> For all use cases I have seen so far either
> 1. pipelining was adequate for it
> 2. or examples where as you described with optimizations for  
> multiple operations (security checks, dbms lookup, etc.)
>
> Case 2 could be betterh andled (e.g. without changing the worldwide  
> HTTP implementation) by optimizing the URL namespace. What I mean is  
> that one adds URLs to the application which represent specific views  
> on multiple resources. Those you can then retrieve with a single GET.
>
> Look how google does it. They have given the first 20 search results  
> a single URL.

Yes, maybe. However, my question/motiviation is quite specific and not  
strictly related to plain HTTP. (extending HTTP using hardcoded  
namespaces is not done by any WebDAV protocol, good or bad, thats the  
'style' of those).

Again, my basic motivation is to consolidate the CalDAV/CardDAV/xyzDAV  
multiget REPORTs, not necessarily to provide a generic BATCH  
capability (though it would be very nice if we can usefully catch this  
with one memo).
Those specialized batch ops already exist and won't get removed.

Now I would prefer to do the batch thing in a generic way, but if the  
outcome is that this is too hard (eg because Servlets can't easily  
hook into the HTTP stack), we could also do a specialized REPORT  
(instead of a new, plain-HTTP, non WebDAV-specific BATCH method).


On 29.05.2008, at 10:35, Julian Reschke wrote:
> Actually, my proposal allows a server to assign a GETtable URI to  
> any REPORT response, so a client would have an extremely simply way  
> to find out about the URI.

Maybe I'm reading your memo wrong, but to me it does not look like a  
BATCH or multiget REPORT replacement. You would need to encode all  
requested URIs in the URL or assign a stateful token.

Its not that useful to cache changeset information either (because it  
constantly changes and is client-cache specific). Its more important  
to cache the contained, individual contents. In fact for the latter a  
BATCH looks to be optimal, since the actual content caching is exactly  
the same like for individual contents, whereas a REPORT needs custom  
infrastructure.

I can see that your proposal is useful for other kinds of reports  
(more in the GData feed-like category).

Thanks,
   Helge

PS: I think BATCH would be relatively easy to implement in the Apache2  
infrastructure.
-- 
Helge Hess
http://www.helgehess.eu/

Received on Thursday, 29 May 2008 09:08:24 UTC