Re: Optional Backpointers from Targets to References

>Could you be more specific about the kinds of scalability problems you
>envision?

A resource can be referenced by any collection anywhere on the web.
Maintaining backreferences to such collections requires that you are
both notified when a reference is made/unmade and have the ability
to store an unbounded number of backlinks in the repository, which is
an area of concern when they may come from other (untrusted) administrative
domains.  The continual cost of maintaining such links is not worth the
occasional use.

This is, of course, not the case for most DMS.  They would undoubtedly
restrict the mantenance of backlinks to collections held within the DMS.

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

Yes.

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

It would be live in the same sense that the members of a collection
are live (determined by the server and not directly set by the client).

....Roy

Received on Monday, 21 September 1998 19:14:44 UTC