Re: Issue: ALLPROP_AND_COMPUTED

On Fri, May 04, 2001 at 11:33:59AM -0700, Dan Brotsky wrote:
> At 12:45 PM -0400 5/4/01, Jason Crawford wrote:
> >As it stands now, I have a mild preference for leaving allprop in.  I'm
> >*very* willing to support another position if it will bring us to agreement
> >and not do any serious damage.
> 
> That was the point I was trying to make (apparently not very well :^) 
> in my earlier message.  The problem with leaving ALLPROP in is that 
> we're clearly going to be changing its semantics (e.g., forbidding
        ^^^^

"clearly" is not all that clear :-) ... assuming it is left in, then I
believe we'll make some guidance as to how clients should use it, and what
servers can do when they see it. But changing its semantics would be a
backwards-compat bitch.

IMO, we just note that servers are allowed to return errors on
allprop/infinity if they want to (just because, or because they see that it
will be too expensive).

>...
> I think the only problem with this plan is that folks are worried 
> about the extra work clients will have to do to do PROPNAME/PROPFIND 
> pairs (with unioning) rather than a simple ALLPROP.  So I ask again 
> (as a client implementor who doesn't mind doing this):  are there any 
> client-side folks out there who believe the extra work is too 
> onerous?

Yes. It is burdensome when the existing specification meets my needs
exactly.

Nobody has yet shown that the existing spec is *broken*. The only thing
raised so far is "it bogs the server when computed props exist" and the
alternative to do a propname/propfind; but the alternative has the *same*
server performance characteristics. And I maintain worse perf from a
systemwide standpoint.

> And, if so, do you have clear requirements for what an 
> updated ALLPROP needs to do in order to work for you?

Personally, I would recommend leaving it just as it is, with a note in the
spec that the server can return <this> error in certain cases. The client
should interpret that as "whoops. we asked too much" and back off to a nicer
algorithm. (and better yet, just start with the nice one)


For my particular scenario, the "fetch by namespace" would be ideal. I could
put all of the SVN user properties into a particular namespace and just
fetch those.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 4 May 2001 21:08:22 UTC