RE: Client Option for Strong References

How about looking at it this way...

A reference can be referring to one of two things.

A. It is referring to a location in the URL namespace (consequentially
referring whatever resource is available there)
B. It is referring to a specific resource (consequentially it should follow
that resource as it moves)

Type A corresponds to "weak" references. Type B is what we have been calling
"strong".

We can throw out the strong/weak/integrity characterization. I think this
more closely matches what servers/clients actually want to use references
for.

Type A references cannot be "dangling" since they reference a specific
location irrespective of the existence of a resource there.

If a reference of Type B loses track of the resource it is referring to,
then it can revert to a Type A reference to the last place it knew about the
resource. Thus what "dangling" is also handled for Type B. 

Also creation of Type B references would be server optional, it should be
possible to decide to make Type A references non-optional.

Typically only Type A references will be possible across servers since we
don't yet have a standard way of tracking resources independent of URL.

How about the terms "location reference" and "resource reference".

Note that these would be orthogonal to direct/indirect references.

Marcus.

> -----Original Message-----
> From:	Slein, Judith A [SMTP:JSlein@crt.xerox.com]
> Sent:	Wednesday, October 07, 1998 08:48
> To:	'WebDAV'
> Subject:	Client Option for Strong References
> 
> Here is the promised summary of the conference call discussions related to
> this issue.
> 
> Issue:  Should the client be able to request creation of a reference whose
> referential integrity is not to be enforced?
> 
> Scenarios offered in support of this requirement: 
> 
> The owner of a target resource needs to take it offline for a short period
> of time, say a week.  It would be useful for the references to that target
> to stay in place.  During the period when the target does not exist, the
> server responds to GET requests with "404 Not Found", but when the target
> is
> restored, the references work again without having to be recreated.
> 
> A collection administrator may decide to create references now, in
> anticipation of targets being available in the near future.
> 
> Arguments:
> 
> It is unlikely that a server implementor would allow referential integrity
> to be turned on or off.
> 
> What are the semantics of dangling references like?  Will they really
> reconnect automatically if the target is recreated?  We need to understand
> the semantics of dangling references before we can see whether this
> requirement makes sense.
> 
> It was agreed that if we give the client a choice, it should be at
> reference
> creation time, not at target deletion time.
> 
> General discussion about referential integrity:
> 
> The best we can expect from any server for referential integrity is best
> effort.  Probably referential integrity will be implemented only for cases
> where reference and target are on the same server or a family of
> collaborating servers.  Even then, it may not be possible (disks may not
> be
> mounted).  Some servers may support multiple back ends, some of which will
> preserve referential integrity, while others do not.  The same server may
> change over time, supporting referential integrity at some times but not
> at
> others.
> 
> Apache will not implement referential integrity for direct references.
> Implementing referential integrity must be optional.
> 
> Servers may or may not perform consistency operations.  Do clients need to
> know whether they do or not?
> 
> We decided at Redmond to include referential integrity in the
> requirements,
> but to defer everything related to referential integrity for the protocol.
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
>

Received on Wednesday, 7 October 1998 15:34:07 UTC