Changeset: 181666753d35 for MonetDB
URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=181666753d35
Modified Files:
monetdb5/mal/mal_authorize.mx
monetdb5/mal/mal_box.mx
monetdb5/mal/mal_builder.mx
monetdb5/mal/mal_client.mx
monetdb5/mal/mal_debugger.mx
monetdb5/mal/mal_exception.mx
monetdb5/mal/mal_function.mx
monetdb5/mal/mal_parser.mx
monetdb5/mal/mal_scenario.mx
Branch: headless
Log Message:
Almost done with pass one over MAL directory
The mal_interpreter code should be split
The mal_parser could be simplified if we
had a thread safe parser generator.
diffs (truncated from 2636 to 300 lines):
diff --git a/monetdb5/mal/mal_authorize.mx b/monetdb5/mal/mal_authorize.mx
--- a/monetdb5/mal/mal_authorize.mx
+++ b/monetdb5/mal/mal_authorize.mx
@@ -17,17 +17,6 @@
All Rights Reserved.
@
-@f mal_authorize
-@a M. Kersten, F. Groffen
-@v 0.3
-@+ Authorisation adminstration management
-Authorisation of users is a key concept in protecting the server from
-malicious and unauthorised users. This file contains a number of
-functions that administrate a set of BATs backing the authorisation
-tables.
-
-The implementation is based on three persistent BATs, which keep the
-usernames, passwords and allowed scenarios for users of the server.
@h
#ifndef _MAL_AUTHORIZE_H
@@ -62,34 +51,43 @@
mal_export str AUTHSHA2Sum(str *ret, str *string, int *len, int *number);
mal_export str AUTHBackendSum(str *ret, str *string, int *len);
-@-
-Authorisation is based on a password. The passwords are stored hashed
-in a BAT. Access to this BAT is ok from the MAL level, and in
-particular SQL needs it to dump (and later restore) users.
-The database administrator can unlock the BAT that stores the password
-(the vault) by supplying the master password which is the key for the
-cypher algorithm used to store the data. The BAT will never
-contain the plain hashes, as they will be decyphered on the fly when
-needed. A locked vault means noone can log into the system, hence, the
-vault needs to be unlocked as part of the server startup ritual.
-@h
+/*
+ * Authorisation is based on a password. The passwords are stored hashed
+ * in a BAT. Access to this BAT is ok from the MAL level, and in
+ * particular SQL needs it to dump (and later restore) users.
+ * The database administrator can unlock the BAT that stores the password
+ * (the vault) by supplying the master password which is the key for the
+ * cypher algorithm used to store the data. The BAT will never
+ * contain the plain hashes, as they will be decyphered on the fly when
+ * needed. A locked vault means noone can log into the system, hence, the
+ * vault needs to be unlocked as part of the server startup ritual.
+*/
mal_export str AUTHunlockVault(str *password);
-@-
-To avoid the password hashes from being sent over the wire in their
-original format (and allowing repeatability attacks), MAPI starts with
-sending a challenge with salt. This salt should be appended to the
-password hash before it is hashed again in order to make the password
-unreadable for eavesdroppers. The hash algorithm used is specified by
-the client, and can be chosen from a comma separated list offered by the
-server through the challenge (protocol >=6). As of protocol version 9
-the crypt algorithm has been removed.
-@h
+/*
+ * To avoid the password hashes from being sent over the wire in their
+ * original format (and allowing repeatability attacks), MAPI starts with
+ * sending a challenge with salt. This salt should be appended to the
+ * password hash before it is hashed again in order to make the password
+ * unreadable for eavesdroppers. The hash algorithm used is specified by
+ * the client, and can be chosen from a comma separated list offered by the
+ * server through the challenge (protocol >=6). As of protocol version 9
+ * the crypt algorithm has been removed.
+*/
mal_export str AUTHgetHashAlgorithms(str *ret);
#endif /* _MAL_AUTHORIZE_H */
-@-
+
@c
+/* Author(s) M.L. Kersten, F. Groffen
+/* Authorisation adminstration management
+ * Authorisation of users is a key concept in protecting the server from
+ * malicious and unauthorised users. This file contains a number of
+ * functions that administrate a set of BATs backing the authorisation tables.
+ *
+ * The implementation is based on three persistent BATs, which keep the
+ * usernames, passwords and allowed scenarios for users of the server.
+*/
@{
#include "monetdb_config.h"
#include "mal_authorize.h"
@@ -175,14 +173,14 @@
TMsubcommit_list(blist, 4);
}
-@-
-Localize the authorization tables in the database. The authorization
-tables are a set of aligned BATs that store username, password (hashed)
-and scenario permissions.
-If the BATs do not exist, they are created, and the monetdb/monetdb
-administrator account is added. Initialising the authorization tables
-can only be done after the GDK kernel has been initialized.
-@c
+/*
+ * Localize the authorization tables in the database. The authorization
+ * tables are a set of aligned BATs that store username, password (hashed)
+ * and scenario permissions.
+ * If the BATs do not exist, they are created, and the monetdb/monetdb
+ * administrator account is added. Initialising the authorization tables
+ * can only be done after the GDK kernel has been initialized.
+*/
str
AUTHinitTables() {
bat bid;
@@ -1397,4 +1395,3 @@
return(MAL_SUCCEED);
}
-@}
diff --git a/monetdb5/mal/mal_box.mx b/monetdb5/mal/mal_box.mx
--- a/monetdb5/mal/mal_box.mx
+++ b/monetdb5/mal/mal_box.mx
@@ -17,191 +17,7 @@
All Rights Reserved.
@
-@a M.L. Kersten
-@+ Boxed Variables
-Clients sessions often come with a global scope of variable settings.
-Access to these global variables should be easy,
-but they should also provide protection against concurrent update
-when the client wishes to perform parallel processing.
-Likewise, databases, query languages, etc. may define constants and variables
-accessible, e.g., relational schemas, to a selected user group.
-The approach taken is to rely on persistent object spaces
-as pioniered in Lynda and -later- JavaSpaces.
-They are called boxes in MonetDB and act as managed containers
-for persistent variables.
-
-Before a client program can interact with a box, it
-should open it, passing qualifying authorization
-information and parameters to instruct the box-manager
-of the intended use. A built-in box is implicitly
-opened when you request for its service.
-
-At the end of a session, the box should be closed. Some box-managers
-may implement a lease-scheme to automatically close interaction
-with a client when the lease runs out. Likewise, the box can
-be notified when the last reference to a leased object
-ceases to exist.
-
-A box can be extended with a new object using the function
-deposit(name) with name a local variable.
-The default implementation silently accepts any new definition of the box.
-If the variable was known already in the box, its value is overwritten.
-
-A local copy of an object can be obtained using the
-pattern 'take(name,[param])', where name denotes the variable
-of interest. The type of the receiving variable should
-match the one known for the object. Whether an actual
-copy is produced or a reference to a shared object
-is returned is defined by the box manager.
-
-The object is given back to the box manager calling 'release(name)'.
-It may update the content of the repository accordingly, release locks,
-and move the value to persistent store. Whatever the semantics
-of the box requires. [The default implementation is a no-op]
-
-Finally, the object manager can be requested to 'discard(name)'
-a variable completely. The default implementation is to reclaim
-the space in the box.
-
-Concurrency control, replication services, as well as access
-to remote stores may be delegated to a box manager.
-Depending on the intended semantics, the box manager
-may keep track of the clients holding links to this members,
-provide a traditional 2-phase
-locking scheme, optimistic control, or check-out/check-in scheme.
-In all cases, these management issues are transparant to the
-main thread (=client) of control, which operates on a temporary
-snapshot. For the time being we realize the managers as critical
-code sections, i.e. one client is permitted access to the box space
-at a time.
-
-Fo example, consider the client function:
-@example
-function myfcn():void;
- b:bat[:oid,:int] := bbp.take("mytable");
- c:bat[:int,:str] := sql.take("person","age");
- d:= intersect(b,c);
- io.print(d);
- u:str:= client.take(user);
- io.print(u);
- client.release(user);
-end function;
-@end example
-
-The function binds to a copy from the local persistent BAT space,
-much like bat-names are resolved in earlier MonetDB versions. The second
-statement uses an implementation of take that searches a variable
-of interest using two string properties. It illustrates that
-a box manager is free to extend/overload the predefined scheme,
-which is geared towards storing MAL variables.
-
-The result bat @sc{c} is temporary and disappears upon garbage
-collection. The variable @sc{u} is looked up as the string object user.
-
-Note that BATs @sc{b} and @sc{c} need be released at some point. In general
-this point in time does not coincide with a computational boundary
-like a function return. During a session, several bats may be taken
-out of the box, being processed, and only at the end of a session
-being released. In this example, it means that the reference to
-b and c is lost at the end of the function (due to garbarge collection)
-and that subsequent use requires another take() call.
-The box manager bbp is notified of the implicit release and
-can take garbage collection actions.
-
-The box may be inspected at several times during a scenario run.
-The first time is when the MAL program is type-checked for the
-box operations. Typechecking a take() function is tricky.
-If the argument is a string literal, the box can be queried
-directly for the objects' type.
-If found, its type is matched against the lhs variable.
-This strategy fails in the situation when at
-runtime the object is subsequently replaced by another
-typed-instance in the box. We assume this not to happen and
-the exceptions it raises a valuable advice to reconsider
-the programming style.
-
-The type indicator for the destination variable should be
-provided to proceed with proper type checking.
-It can resolve overloaded function selection.
-
-Inspection of the Box can be encoded using an iterator at the MAL
-layer and relying on the functionality of the box.
-However, to improve introspection, we assume that all box
-implementations provide a few rudimentary functions, called objects(arglist)
-and dir(arglist). The function objects() produces a BAT with
-the object names, possibly limited to those identified by
-the arglist.
-
-The world of boxes has not been explored deeply yet.
-It is envisioned that it could play a role to import/export
-different objects, e.g.,
-introduce xml.take() which converts an XML document to a BAT,
-jpeg.take() similer for an image.
-
-Nesting boxes is possible. It provides a simple
-containment scheme between boxes, but in general will interfere with
-the semantics of each box.
-
-Each box has (should) have an access control list, which names
-the users having permission to read/write its content.
-The first one to create the box becomes the owner. He may grant/revoke
-access to the box to users on a selective basis.
-
-@- Session Box
-Aside from box associated with the modules, a session box is created
-dynamically on behalf of each client. Such boxes are considered private
-and require access by the user name (and password).
-At the end of a session they are closed, which means that they are
-saved in persistent store until the next session starts.
-For example:
-@example
-function m():void;
- box.open("client_name");
- box.deposit("client_name","pi",3.417:flt);
- f:flt := box.take("client_name","pi");
- io.print(t);
- box.close("client_name");
-end function;
-@end example
-@-
-In the namespace it is placed subordinate to any space introduced by the
-system administrator. It will contain global client data, e.g.,
-user, language, database, port, and any other session parameter.
-The boxes are all collected in the context of the database directory,
-i.e. the directory <dbfarm>/box
-
-@- Garbage Collection
-The key objects managed by MonetDB are the persistent BATs, which
-call for an efficient scheme to make them accessible for manipulation
-in the MAL procedures taking into account a possibly hostile
-parallel access.
-
-Most kernel routines produce BATs as a result, which will be referenced
-from the runtime stack. They should be garbage collected as soon as
-deemed possible to free-up space. By default, temporary results are
-garbage collected before returning from a MAL function.
-
-@- Globale Environment
-The top level interaction keeps a 'box' with global variables,
-i.e. each MAL statement is interpreted in an already initialized
-stack frame.
-This causes the following problems: 1) how to get rid of global variables
-and 2) how to deal with variables that can take 'any' type.
-It is illustrated as follows:
-@example
-f:= const.take("dbname");
-io.print(f);
-@end example
-When executed in the context of a function, the answer will be
-simple [ nil ]. The reason is that the expecteed type is not known
_______________________________________________
Checkin-list mailing list
[email protected]
http://mail.monetdb.org/mailman/listinfo/checkin-list
