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