Subject: RE: [nfsv4] Conference call -- directory delegations

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 20 Jan 2006 08:11:03 -0500

> 	At CITI, Trond made a good point for separating them: if it
turns
> out that notifications don't work well or aren't enough of a "win",
> keeping open the possibility of dropping them in a future minor
version
> would be important.  Eliding dir. delegations and notifications in a
> single operation would prevent this.

Why?  If they are separately optional, i.e. you are allowed to implement

delegations and not notifications, then it would be possible to make it
mandatory to not implement notifications and then everybody would be 
required to behave like clients who don't support notifications.  And,
if they generated no interest, it is likely that that would be most 
implementations, so most people would go from optionally returning an
indication of no support for notifications to being required to return 
an indication of no support for notifications.  No big deal.  It is 
exactly what would happen if they were a separate operation and that 
became mandatory to not implement.

> 	As such, I am curious what everyone's feelings are about
> separating the two.  We could introduce a separate operation,
> REQUEST_NOTIFICATION (whatever), that would implement Saadia's
> notification scheme.  That operation could depend on the client
already
> possessing a delegation on the directory in question.  Notifications
could
> still implicitly end when the delegation is recalled.

It seems to me that they are just as tied together in that scheme as the
current one.  You have to have use feature A to use feature B.  You have

to implement feature A to implement feature B.  So they are tied
together.
I don't see what you have accomplished by "separating" them.

> 	Given that the client would have to probe for delegation and
> notification capabilities on the server anyway, it seems to me that
> having two separate operations, with two separate (though related)
> purposes and sets of arguments and implementation details, would have
a
> higher conceptual integrity than the current draft proposal.  Put
another
> way, can anyone present a case for _not_ separating them?

"conceptual integrity" is something that people will differ on.  I think
of these as related mainly because the primary use of notifications is
for the client to keep his view of the directory up to date in a
situation
where he has a copy, which makes associating with delegations natural.
I think the fact that nobody has made a proposal that really separates
them suggests that it is hard to do.  Putting things in a spearate op,
while maintaining all the current linkages between the two features is
not really separating them.

-----Original Message-----
From: david m. richter [mailto:[email-masked]] 
Sent: Thursday, January 19, 2006 4:50 PM
To: [email-masked]
Subject: [nfsv4] Conference call -- directory delegations

	Hello, I'd like to follow-up on the points raised about
directory
delegations.  Chiefly, I'm interested in the discussion of separating
dir. delegations from notifications.

	At CITI, Trond made a good point for separating them: if it
turns
out that notifications don't work well or aren't enough of a "win",
keeping open the possibility of dropping them in a future minor version
would be important.  Eliding dir. delegations and notifications in a
single operation would prevent this.

	I also have some concern about the increased complexity of
implementation and server state coming from an untested(?) proposal,
particularly since we know for sure that delegations alone will provide
significant gains.  Exposing notifications to a userland API, e.g.,
would
increase their utility, but I'm taken to believe that's not intended.

	As such, I am curious what everyone's feelings are about
separating the two.  We could introduce a separate operation,
REQUEST_NOTIFICATION (whatever), that would implement Saadia's
notification scheme.  That operation could depend on the client already
possessing a delegation on the directory in question.  Notifications
could
still implicitly end when the delegation is recalled.

	Given that the client would have to probe for delegation and
notification capabilities on the server anyway, it seems to me that
having two separate operations, with two separate (though related)
purposes and sets of arguments and implementation details, would have a
higher conceptual integrity than the current draft proposal.  Put
another
way, can anyone present a case for _not_ separating them?

	Please, align your crosshairs and have-at.

	thanks,

	d
	.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4