diff options
| author | Russ Allbery <rra@stanford.edu> | 2007-08-27 16:53:33 +0000 | 
|---|---|---|
| committer | Russ Allbery <rra@stanford.edu> | 2007-08-27 16:53:33 +0000 | 
| commit | 60f6567822d9a9a13a3395097656af7220c7b31e (patch) | |
| tree | bc042534c65320bd3ea89ae95016d65acfc15979 /docs | |
| parent | 10c21db62ffe14c6f208cbfa938f72bc4876f594 (diff) | |
Rename delete to destroy in the API and MySQL fields to avoid the Perl
delete keyword.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/design | 21 | ||||
| -rw-r--r-- | docs/design-api | 2 | ||||
| -rw-r--r-- | docs/design-schema | 14 | ||||
| -rw-r--r-- | docs/notes | 8 | 
4 files changed, 15 insertions, 30 deletions
| diff --git a/docs/design b/docs/design index 541026c..a146514 100644 --- a/docs/design +++ b/docs/design @@ -67,7 +67,7 @@ Server Design      object:          create          Create a new wallet entry for an object -        delete          Delete the wallet entry for a given object +        destroy         Delete the wallet entry for a given object          owner           Set the owner of an object          acl             Set the ACL on an object          flag            Set or clear flags on an object @@ -76,14 +76,8 @@ Server Design          get             Retrieve the named object from the wallet          store           Store the named object in the wallet -        group-add       Add a principal to an ACL group -        group-remove    Remove a principal from an ACL group -        group-list      List the members of an ACL group -      The first six operations manipulate or display the metadata of the      object.  The next two operations store or retrieve the object itself. -    The last three operations allow manipulation of krb5-group ACLs (see -    below).      The owner and acl operations are only available to wallet      administrators.  Even if one is the listed owner of an object, one may @@ -111,15 +105,6 @@ Server Design      principal name as an identifier; only that principal will be      authorized by that ACL line. -    An ACL line of scheme krb5-group will have a group name as an -    identifier.  That group will have an owner and a list of Kerberos -    principals.  Any Kerberos principals on the list (not including the -    separate owner) will be authorized by that ACL line.  The owner is -    itself a reference to another ACL, which may include the group for a -    self-owning ACL.  Anyone on the ACL referenced by the owner attribute -    may list the principals in that group and add or remove a principal -    from that group. -      An ACL line of scheme netdb will have an identifier naming a specific      machine.  The user will be authorized if that user has a role of      "admin" or "team" for that machine.  See netdb-role-api for the @@ -153,10 +138,10 @@ Server Design        reference to an ACL of one line, that line having scheme "krb5" and        identifier "rra/root@stanford.edu". -    * Optional ACLs for get, store, show, delete, and flag operations. +    * Optional ACLs for get, store, show, destroy, and flag operations.        If there is an ACL for get, store, or show, that overrides the        normal permissions of the owner.  In the absence of an ACL for -      delete or flag, only wallet administrators can delete an object or +      destroy or flag, only wallet administrators can destroy an object or        set flags on that object.  This entry would need no special ACLs.      * Trace fields storing the user, remote host, and timestamp for when diff --git a/docs/design-api b/docs/design-api index 9ef3901..b0363d4 100644 --- a/docs/design-api +++ b/docs/design-api @@ -67,7 +67,7 @@ Object API      and returns 1 if those default authorization rules allow access.  If      there are no authorization rules or if they don't allow access,      returns 0.  On error, returns undef; the caller should call error() to -    get the error text.  Operation should be one of get, store, delete, +    get the error text.  Operation should be one of get, store, destroy,      show, and flags.    error() diff --git a/docs/design-schema b/docs/design-schema index 14e880e..648c367 100644 --- a/docs/design-schema +++ b/docs/design-schema @@ -23,7 +23,7 @@ Object Metadata            ob_acl_get            integer default null references acls(ac_id),            ob_acl_store          integer default null references acls(ac_id),            ob_acl_show           integer default null references acls(ac_id), -          ob_acl_delete         integer default null references acls(ac_id), +          ob_acl_destroy        integer default null references acls(ac_id),            ob_acl_flags          integer default null references acls(ac_id),            ob_expires            datetime default null,            ob_created_by         varchar(255) not null, @@ -80,10 +80,10 @@ Object Metadata            oh_type               varchar(16)                not null references objects(ob_type),            oh_action -               enum('create', 'delete', 'get', 'store', set') not null, +               enum('create', 'destroy', 'get', 'store', set') not null,            oh_field                enum('owner', 'acl_get', 'acl_store', 'acl_show', -                   'acl_delete', 'acl_flags', 'expires', 'flags', +                   'acl_destroy', 'acl_flags', 'expires', 'flags',                     'type_data'),            oh_type_field         varchar(255),            oh_from               varchar(255), @@ -93,7 +93,7 @@ Object Metadata            oh_on                 datetime not null,            primary key (oh_object, oh_type)); -    For a change of type create, get, store, or delete, only the action +    For a change of type create, get, store, or destroy, only the action      and the trace records (by, from, and on) are stored.  For changes to      columns or to the flags table, oh_field takes what attribute is      changed, oh_from takes the previous value converted to a string and @@ -108,7 +108,7 @@ Object Metadata        create table acl_history           (ah_id                 integer auto_increment primary key,            ah_acl                integer not null, -          ah_action             enum('create', 'delete', 'add', 'remove') +          ah_action             enum('create', 'destroy', 'add', 'remove')                not null,            ah_scheme             varchar(32),            ah_identifier         varchar(255), @@ -116,10 +116,10 @@ Object Metadata            ah_from               varchar(255) not null,            ah_on                 datetime not null); -    For a change of type create or delete, only the action and the trace +    For a change of type create or destroy, only the action and the trace      records (by, from, and on) are stored.  For a change to the lines of      an ACL, the scheme and identifier of the line that was added or -    deleted is included.  Note that changes to the ACL name are not +    removed is included.  Note that changes to the ACL name are not      recorded; ACLs are always tracked by system-generated ID, so name      changes are purely cosmetic. @@ -43,7 +43,7 @@ Server Issues    ACL Management      Supported operations are:  get, store, create (triggered by a get or -    store of something that didn't already exist), delete, show, and +    store of something that didn't already exist), destroy, show, and      setting or clearing flags.  Each of these need a separate ACL      potentially.  Not sure if we're going to need separate ACLs for each      flag operation. @@ -56,8 +56,8 @@ Server Issues      with, for instance, ACL management via NetDB roles for systems that      have no more specific ACL. -    Owner rights provides get, store, and show, but not delete or setting -    or clearing flags (not delete because it's too destructive and we +    Owner rights provides get, store, and show, but not destroy or setting +    or clearing flags (not destroy because it's too destructive and we      don't want it done accidentally).  This can be overridden by more      precise ACL settings.  So the ACL logic would go like this: @@ -100,7 +100,7 @@ Server Issues      The database has a field to store an expiration date for every object.      We can implement expiration methods in the backend to automatically -    delete some objects (or perhaps lock them) when they pass their +    destroy some objects (or perhaps lock them) when they pass their      expiration date, but a more useful method might be to provide warnings      when objects are about to expire via warning methods for a backend      that take the object name and the expiration date.  This would be | 
