RE: v0.2 draft Distributed Editing Reqts.

>
>>  2. Relationships. Via HTTP, it should be possible to create, query, and
>>     delete typed relationships (links) between entities of any media type.
>>
>>     Relationships (or links which are not necessarily navigable) between
>>     entities can be used for many purposes. Relationships can support
>>     pushbutton printing of a multi-resource document in a prescribed order,
>>     jumping to the access control page for an entity, and quick browsing of
>>     related information, such as a table of contents, an index, a glossary,
>>     help pages, etc. While relationship support is provided by the HTML
>>     "LINK" element, this is limited only to HTML entities, and does not
>>     support bitmap image types, and other non-HTML media types.
>>     Aolpress From America Online [1] currently "allows pages to add toolbar
>>     buttons on the fly using the HTML 3.2 <LINK REL....> tag. For example,
>>     your page can add toolbar buttons that link to a home page, table of
>>     contents, index, glossary, copyright page, next page, previous page,
>>     help page, higher level page, or a bookmark in the document."
>
>The mention of links confuses the paragraph. You start off by equating
>Links to relationships (which I think is proper but that is another
>story) and then go on to say that links may not be navigable, even
>though relationships must be. I understand you do not want to be seen as
>supporting any particular implementation type. I would suggest removing
>the references to links, I think the requirement stands on its own.

By (hypertext) link, I usually mean "that subset of relationships which are
browsable using the hypertext point-and-click navigation user interface."
This is not consistent with the meaning I use in the text above.  I'll work
more on the wording...

>>     An author may wish to lock an entire web of entities even though they
>>     are editing just a single entity, to keep the other entities from
>>     changing. In this way, an author can ensure that if a local hypertext
>>     web is consistent in their distributed authoring tool, it will then be
>>     consistent when they write it to the server. Because of this, it should
>>     be possible to take out a lock without also causing transmission of the
>>     contents of an entity. Since it should not be assumed that because an
>>     entity is locked, that it will necessarily be modified, and since many
>>     people may wish to have simultaneous guarantees that an entity will not
>>     be modified, but still not want to modify the entity themselves, it is
>>     desirable to have a "read" lock capability. A read lock, by being less
>>     restrictive, provides better support than a write lock for providing a
>>     guarantee that an entity will not be modified.
>
>O.K. I'm confused. What is the difference between a write lock and a
>read lock? I was brought up to believe that a write lock means only
>someone with a lock may write to the file and a read lock means only
>someone with a lock may even read the file. Do I need to change
>religions?

An entity is *always* readable under HTTP, independent of what kind of lock
(read, write, none) exists on it.  A read lock only says that the entity is
guaranteed not to change for the duration of the lock.  A write lock says
an entity is guaranteed not to change only if the owner of the lock does
not change it, and only the owner of the write may change it.

Perhaps the name "read" lock should be changed to something more meaningful.

>
>In addition I think we need an explicit statement that locks must allow
>for multiple files under a single lock. Hence the user can always be
>sure that whenever they perform any action under the auspices of a
>multiple file lock, such as a GET or PUT, the action will either go
>through, meaning all files under the lock remain locked, or the action
>will be rejected with an error indicating that one or more files under a
>lock have been removed from that lock.

Such higher level locking actions can be implemented using single-entity
locks, and hence I'd prefer not to introduce the added complexity of
multiple entity simultaneous locks.

- Jim

Received on Friday, 6 September 1996 14:57:09 UTC