W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

RE: Optional Backpointers from Targets to References

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Mon, 21 Sep 1998 15:48:46 -0400
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C73@x-wb-0128-nt8.wrc.xerox.com>
To: "'Roy T. Fielding'" <fielding@kiwi.ics.uci.edu>
Cc: "'WebDAV'" <w3c-dist-auth@w3.org>
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ics.uci.edu]
> Sent: Friday, September 18, 1998 9:32 PM
> To: Slein, Judith A
> Cc: 'WebDAV'
> Subject: Re: Optional Backpointers from Targets to References 
> I doubt that unrestricted backpointers to collection parents will be
> implementable on general web servers, but I have no objection 
> to defining
> an optional backpointer property provided that it is also 
> mentioned that
> such a property is not a very good way to implement scalable systems.

Could you be more specific about the kinds of scalability problems you

> The same functionality can be accomplished via a DASL query, 
> regardless
> of how the server backend works, which has the advantage of specifying
> the scope of the query.  So, I don't think directly specifying
> a property to hold that information should imply that the property is
> maintained live.  OTOH, I'm not sure how the response to such a DASL
> query would look like (i.e., if it would need DAV:references itself).

You are thinking the query would be:

Find the resources on server S that have DAV:reftarget = T?

This is certainly possible in cases where the client has a certain list of
servers that it cares about.  This includes the case that motivated the
suggestion about backpointers in the first place -- DMSs. It's less useful
for more open-ended cases like the client just trying to find out who would
be affected if it deletes a resource. 

It does seem to me that the property should be live if it exists at all.
Otherwise the property value will just be unreliable, since some clients
that create references may maintain it while others do not.

Received on Monday, 21 September 1998 16:04:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:18 UTC