Access Controls

[David Merrill]

On Sat, Dec 30, 2000 at 01:04:01AM -0600, linas@linas.org wrote:
> 
> It's been rumoured that David Merrill said:
> > 
> > Option 1, no concurrent edits allowed:
> > 
> > client 1 -> server "I want to edit record 1"
> > server -> client 1 "OK"
> > 
> > client 2 -> server "I want to edit record 1"
> > server -> client 2 "NO"
> > 
> > Only one user can edit at a time. Easy to implement; can be
> > frustrating to the user.
> 
> esp. if user 1 leaves for lunch, or ^C's out.

Oh yeah. Shudders. 

> > Option 2, concurrency allowed, changes are merged:
> > 
> > In order to merge changes, the db has to know the state of the data
> > the user was editing, as well as the new state of the data. But a
> > mechanism for retaining a complete audit trail is already in place for
> > other reasons, so why not use it for this? So if we take the cvs
> > approach, it could work like this:
> > 
> > client -> server "Here is an update to record 1"
> 
> client->server "here is what I think record 1 used to be, 
>                 and here's what I want it to be".

Yes.

Wow! Already I'm getting patches! :-)

> > server checks to see if record still exists in transaction table
> > 
> > IF YES	
>     compare clients original to server's original.
>     if identical, 
> >       move original record to audit table
> > 	save new record in transaction table
> > 	server -> client "OK"
>     if not identical,
>         compare clients update to servers original
>         if identical,
>              server -> client "OK"  /* another user has already made the
>                                      * same exact change */
>         if not identical, 
>  	     server -> client "TRY AGAIN"

Yes.

> > The only failure happens when two or more users have edited the same
> > field concurrently. There's really nothing we can do about that but
> > fail gracefully and let them re-edit if they wish.
> 
> Its better to do it record by record, not field by field, to avoid the 
> following:
> 
> Two  users looking at one record and user1 thinks: geee this is
> wrong, hmm the date is wrong, let me fix the date.  User2 thinks
> 'gee this is wrong, but if I fix the amount then ..."   If we were to
> accept and merge user1 & user2 changes field by field... ughh.

I was attempting to do field by field merges because you suggested
"cvs style". But you're right, the potential for inconsistent edits is
a big problem. 
 
> > Regardless of which concurrency mechanism is used, we still have to
> > provide for data changed by others but not yet updated at the client's
> > machine:
> 
> corba provides an asynchronous event mechanism that soap lacks, and I
> beleive onc-rpc lacks.  We could e.g. do this:
> 
> clienta->server
>    "gimme records 1-100"
> server: notes clienta has 1-100.  If clientb changes record 52, then
>    server notes that clienta must be notified, delivers async event. 
> 
> clienta listens for events, updates when it gets one.

That'll work.

> For rpc or xml/soap, which don't have events, I don't know how to 'roll
> our own', it seems complicated. Firewalls mess things up. I've never
> really fooled with 'web streaming'; it would require leaving a socket
> open to the client, and then there are problems if the socket closes ... 
> i.e. various ugly low-level issues.

I wasn't planning on providing that kind of support because of the
bi-directional requirement. It would be a good thing if we can do it,
though.

> 
> A traditional and somewhat klunky solution is:
> 
> client->server
>      "some mesage"
> server->client
>      "wait, before we get into that, here are changes to stuff 
>      I know you will be interested in"
> 
> 
> Again, traditionally, the server just sends out a 'your data is now
> invalid' message, allowing the client to figure out if it wants to
> refresh or move on to other things.  The most polite message is 
> 'records 1, 23 and 42 are invalid', rather than 'everything you know is
> wrong'.
> 
> There are two varients of this.
> Choice A:
>    server doesn't try to guesss clients state. It simply notes
>    *all* changes since the client last contacted server.
> 
>   server->client
>         "since we last spoke, records 1,23,42 have changed.  I have
>         no clue if you even care about these records, but they changed."
> 
> Choice B:
>    server tries to track client's state.  It only delivers info
>    about what it thinks the client posseses.
> 
>   server->client
>         "I know that once upon a time ask for record 23, and since
>         since we last spoke, record 23 have changed.  
>         (no mention of 1 or 42 is made).
> 
> 
> Choise A doesn't scale well for very busy systems; however, its easier
> cleaner to impelment, far less likely to be buggy.  Choice B is prone
> to nasty bugs.  I vote for A.

I do too. Simpler is always better, if you can do it.

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                dmerrill@lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

The great sea has set me in motion.
Set me adrift,
And I move as a weed in the river.
The arch of sky
And mightiness of storms
Encompasses me,
And I am left
Trembling with joy.