Re: Access Control Preliminary Draft

The only time I can see it being necessary to disallow access to a resource is
if its state is inconsistent due to dependent parts being out of sync (e.g. If
an HTML page is edited and a reference to an image added and this image has not
yet been posted to the server)
-----------------

This is a good example.  I am fairly sure, however, that there are others
which may impose more rigorous requirements, but this is a good descriptive
case.  Your assessment of the possible solutions is exactly what I was
hoping to see in terms of perverse boundary cases that impose the most
stringent requirements on our functionality.  In my case, the solution I
would most likely select for this scenario is the "published version"
approach.  For example, even if a document contains multiple sub parts,
I would not consider it "checked in" until all of it was checked in, so
until all of the new revision is consistent, I would continue to serve
the existing revision (which should already be consistent).  There are
authoring scenarios and/or working styles (for authors) that would make
this difficult, however, and this kind of operability is, IMHO, the kind
of thing we need to hammer out.

For what it's worth, I think it's more clearly important to be able to
lock a collection of resources (whether inherently related or not) for
a wide variety of reasons, so I believe that feature is important in its
own right, but certainly poses a potential solution to your scenario.
I think it's likely that authors will want to make new revisions (or
brand new content) of documents and in particular sets of documents
available at once, so the ability to manage groups of locks in concert
as well as the ability to manage the "published" state of groups of
documents is likely pretty important, both of which relate to this
functionality.  Once this functionality is accepted, it's possible to
use it in a variety of scenarios to support revision management.

Also, I'll stake my opinion on supporting both styles of locks (i.e.
those that prevent a resource from being accessed while locked and
those that don't) particularly since at this point I am more concerned
with an infrastructure that will support future as well as current needs
as best as possible, and I can imagine that what is considered sufficient
to support a facile interface to this functionality may well evolve over
time.  I could also see a solution that involves separating access from
locks entirely, and simply allows the author to choose whether they want
to change the access attributes while the content is locked on their own,
which would allow them to make this decision...  Whether or not these
attributes (access vs. presence of locks) are linked is one question,
but it's clear that we need to both be able to lock resources and to
edit their access attributes, so the question would seem to be, should
these two be automatically linked or should they be separate operations
which may or may not be used together?

-=jack=-

(This text composed by voice)


--

Received on Wednesday, 9 July 1997 12:50:28 UTC