Access Controls

[Derek Atkins]

How about an object "version" number..  The GUID is static for an
object across all changes, but the version number is monotonically
incrased for every change.  The audit trail can be based on the
version number.  A client need only remember the version it has and
can easily determine that an object has changed because the version
number has changed.

Notifications of changes are still possible.

-derek

Christopher Browne <cbbrowne@smtp.hex.net> writes:

> Yes, indeed, this seems an overly conflicted use of GUIDs.
> 
> I _thought_ the point of the exercise was for the GUID to represent
> a permanent unique identifier for an object.
> 
> If it changes, that seems to me to be a Bad Thing.
> 
> There _is_ a reasonable policy to use for this that seems rather
> a lot less abusive:
> 
> -> Generate a new GUID for each entry that gets added to the "audit log."
> 
> -> The audit log should _also_ include a reference to the "active"
>    transaction's GUID, so that one may trace from audit log to the
>    current version of the transaction, and, if there is an index on
>    audit_log-oldGUID, from transactions to audit log.
> 
> Thus, the active transaction doesn't get a new GUID value all the time.
> 
> If there are processes out there that need to know when a particular
> transaction changes, it makes sense to have something analagous to the
> CORBA Notification or Event services rather than changing GUIDs all the
> time.

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available