RE: Proposal: optional backpointers for ACR (Was: RE: Hierarchi cal URLs and Collections)

Ahhh.. the little light goes on. =) I get it.

The solution still bugs me, but only because it leaves so many questions
open. Is it all right to have resources without any parents? This will be
unavoidable with the parent property solution.

What about the law of minimum surprise? When a MKREF is executed you really
can't be sure until after it is over if the back reference got set or not.
What guarantees are we going to require for consistency across resources?

I know this solution was only meant for "hard link" cases but as an
implementers I'm not going to invest in client support for such a limited
situation. I would rather implement the more complex graph solution with the
knowledge that it will give me support across a whole range of server
namespaces.

I would like to hear from some DM implementers. Do you want a limited one
off solution that will only work for hard link supported systems? Do you
want a more general solution at the expensive of a longer development time
and a more complex implementation? What are your needs?

		Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Wednesday, August 19, 1998 7:31 PM
> To: WebDAV
> Subject: RE: Proposal: optional backpointers for ACR (Was: RE:
> Hierarchical URLs and Collections)
> 
> 
> At 05:43 PM 8/19/98 PDT, Yaron Goland wrote:
> >Ick... How about just enhancing ADDREF to accept settings 
> for parents and
> >mandating that parent settings have to be returned in 
> PROPFIND? I believe we
> >should shy away from programmatic properties, even if they 
> are read-only. 
> 
> Uhh, please tell me what you mean by "programmatic".  
> 
> In case I was not clear, what I propose is that when the 
> server sucessfully
> processes a MKREF where the target is T, it also changes the 
> state of  T so
> that a subsequent PROPFIND of T will show the reference R in T's
> dav:references property.
> 
> I don't see how this is any different than the way LOCK 
> changes the state
> of the locked resource so that lock discovery property will 
> return the lock.
> 
> I am certainly not proposing a property that has side-effects.
> 
> If what I am proposing is "programmatic" please explain why 
> it is undesirable.
>

Received on Thursday, 20 August 1998 02:45:35 UTC