RE: Client Option for Strong References

This is a very appealing approach, but at the moment there is a requirement
for strong references:

"3.1.18 It is possible to request creation of a referential resource that
the server will guarantee to have referential integrity."

The rationale is that there are some applications for which dangling
references are unacceptable, and these applications must be able to insure
at the time they create a reference that it will never be broken.

If the group could be persuaded to give up this requirement, we would no
longer need the weak / strong distinction.

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

> -----Original Message-----
> From: Marcus Jager [mailto:mjager@microsoft.com]
> Sent: Wednesday, October 07, 1998 3:34 PM
> To: slein@wrc.xerox.com
> Subject: 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 Thursday, 8 October 1998 09:57:45 UTC