John Cade (JWCADE @ SBCSS.K12.CA.US) suggested:
 
 
>- Roles: rights and privileges granted to a particular application.  We
>have something like this by GRANTing RUN access on tables and procedures.
> This would be useful as part of the API in identifying the PC
>application that is running, identified by a hardcoded **something** in
>the application.
 
What did you have in mind by **something**?  Right now about the best you
can use is USERID (although I must admit that I haven't done too much with
module authorities).  There have been situations in which I would have liked
to be able to GRANT based on the fully qualified userid; i.e.
<session>,<user>.<account>.<group>; it occurs to me that being able to GRANT
by TCP service name/port number might be useful as well.
 
 
>- Encrypted API logon, so that network sniffers could not "see" userids
>and passwords.
Yes!
 
 
>- Database Variables which stay in tact for the duration of a database
>session.  Example: The  custom security table of my application holds
>information about the user@account, let's say, Department-Number.  The
>views in my application allow access to only that department's data.  At
>the beginning of my session, I assign a database variable = dept code
>100, and the view then shows data for dept 100 only.  This method saves a
>sub-select within the view.  In some cases, the subselect could be quite
>nasty, like the department code for the department with the greatest
>number of employees.  I only have to select  it once, and keep it at the
>server end, not the client.
OK.  But let's say that the security for EVAN@RUDDEROW stipulates that I am
allowed to see tuples for departments 100, 101, and 107 -- one variable
won't help in this situation.  I don't know if there's any way to get away
from using a "quite nasty" subselect when dealing with multiple values; I
wish there were...
 
 
>- Callable routines to be able to extend the FUNCTIONS in Allbase.  For
>example, C code to perform some very nasty calculations, then return the
>result to Allbase.  Also, possibly access to the system intrinsics as
>part of the script language.
Why just C?  How about any language which has Allbase support?  The
interesting thing about this request is that it's kind of a reverse approach
to solving the three tiered client/server problem -- what John is proposing
is that, instead of having
 
     presentation server (e.g. PC client)
          <talking to a>
     application server (e.g: the business logic)
          <talking to a>
     database server (i.e.: the database engine)
 
which is the traditional view of the three-tiered C/S model.  We should
instead have:
 
     presentation server (e.g. PC client)
          <talking to a>
     database server (i.e.: the database engine)
          <talking to a>
     application server (i.e.: user written 3GL business logic routines)
 
You know, I wonder if such an approach might not make the three tiered model
easier to implement?  If I want to implement a 3-tier C/S application right
now (and I have) I have to use sockets (or something like that) to pass
messages back and forth between the presentation server and the application
server.  If we use the scrambled (;-)) architecture that John suggests, then
we could use plain old ODBC -- we would just use SQL-Pass-Thru mode to pass
directives for the database engine to invoke user-written external
procedures.
 
Did you follow this?  If so, did I miss something really obvious that makes
this idea stupid or unworkable?
 
 --- Evan