COODBMS release 0.13.1

- 10 more [interactive] commands added to Browse.
- 24 more comands can be used in scripts.
- New wiki page on scripts.
- Backward compatible with release 0.13

COODBMS release 0.13

o Scripts have been implemented with a basic command set--scritps are run as a single transacton.
o Browse now supports keywords, imports and exports.
o Error reporting has been enhanced and now reports the line in a script where the error occured.
o New Wiki page on keywords.

scripts are working!

OK, I've converted the remove command to be interpreted by the server rather than pre-processed by browse. It works. Then I ran a series of removes from a script file. Even that is working.

Now I just need to get a minimum of commands converted and we can start using scripts to configure branches. And that will finally give us the necessary backward compatibility--each release will contain a script for migrating branches forward.

Joy!

RMI

One thing that always happens in retrospect is that I find Norm is right. He always said that language is key and that we needed an interpreter. OK, it isn't the whole answer, but now I see the truth in what he was talking about... more than 6 years later.

I spent the afternoon avoiding the code. Imports and exports are done and I didn't want to tackle the server-side interpreter until I felt good and ready. Finally I dug into the code and learned that this is going to be a very simple change indeed.

There are only 2 small changes needed to get started. First in Browse, if a command is not recognized we execute a transaction with an action that has a CommandLine attribute in place of the OpCode attribute. Easy.

The second small change is in the ActionExec.execute method. There we check and if we have a CommandLine attribute, we call a new rmi method to parse the command line and create the appropriate attributes. And that's it!

Now there is one assumption here--that there is a one-to-one mapping from commands to operations. This looks reasonable.

The next step then will be to augment browse with a "run fileName" command. This command will read a file and create an action for each command in the file, and then submit the whole thing to run as a single transaction. This then will give us an appropriate means of configuring branches and solve the existing problems with backward compatibility.

Piece of cake!

scripting thoughts

Browse currently processes its commands and converts them into RoleML. To implement scripts we can either convert them into RoleML in Browse or interpret them in the server. And to keep Browse light weight, I am in favor of doing the work in the server.

So should we then support both? Why not further simplify Browse by always passing the command to the server? This will also prevent the duplication of a lot of code.

Now some commands are likely best pre-processed by browse and are not candidates for inclusion in a script. Login comes to mind in particular. And there is no immediate need to script all the queries--scripting support can be minimal at first, so long as branches can be configured via a script. So converting over to having commands interpreted by the server can be done incrementally once the basic framework is in place.

keywords, entries

Did some packing for the upcoming move today, but I also wrote a bunch of wiki pages and got two releases out. Besides that I also managed to implement keyword tagging and queries, which is just so much frosting on the cake.

Now I really want to work on RMI, the text script interpreter in the server. We can use this to configure branches and finally gain backword compatability--a really key featue at this point. But to do that, we need to be able to pass text scripts from a client to the server and right now the client side simply does not support entries--which are the means of passing text. So one more side trip to address that: browse commands to import/export text/binary files. Besides, being able to import and export data is also a key feature.

COODBMS 0.12.1

o New Browse commands: removeWellknown, createWellknown, adoptFork, wellknownFork, setUpdateUser and setUpdateGroup.
o Bug fix in server: unexpected socket close when user name missing from a transaction.
o New wiki pages on wellknown, forks, write access and creating user groups.

CowDb 3.3.4

release 3.3.4:
Bug found/fixed: A transaction abort forces the root to be reread, but the ordered app was not clearing the name list prior to reloading.
Bug found/fixed: Wellknown name not cleared when adopting the fork of a wellknown.

Refining intentions

First, clients should be kept as light weight as possible and scripts interpreted on the client side is simply the wrong way to go. Scripts should be executed within a transactional context so we need to have the interpreter in the server itself. This will be called the RoleMagicInterpreter (RMI), an old term of Norm's.

Second, I've found it is best to take a layered approach rather than a monolithic one. Monolithic software is hard to learn, but a layered architecture can be learned in stages. The cost of a layered approach is having to deal with some coupling as well as some impedence mismatch, but then nothing is free. So the smart version of Browse and application modeling should be put in a separate layer, the Metadata OODBMS (MOODBMS, which seems to go well with CowDb), and we'll keep the scope of COODBMS tightly focused. (No web hits on a search for MOODBMS, for the obvious reasons I guess. So we've got a good name from 2 perspectives.)

packing, thinking about versions 1 & 2 of COODBMS

Today my priority is on getting ready for the move to Raipur. Movers will be here Monday and our train leaves on Tuesday evening. But it is also a good time to think things out. COODBMS is at a point where I just need to crank out the rest of the commands for Browse and write some howto docs, and that doesn't allow for much deep thinking.

Priority 1 is of course flushing out Browse and writing those docs. Then all that is left is to stabalize COODBMS so that new releases can run against old databases. At this point the only thing which prevents this the access control--new operations added to the server can not be used without updating all the existing branches. But there is an easy fix to that: scripts.

So the plan now is to have browse runable in script mode and have all future changes to the access control structures released as scripts. Old branches can then be updated easily and new branches will need to have a script run to configure them. The samples showing how to reconfigure access control then should also have sample script files. This all should be quite managable for a COODBMS administrator.

Once version 1 of COODBMS is out, I see a need for a version 2 which focuses on applications. First, we need to model an application. COODBMS should then come with a model of access control as well as a model of application models. But we also need to address extensibility. So the structures defining an application should also define the factory plugins--these would be run at startup and when an application is "installed". Also once we have the ability to model application structures we can implement a smart version of browse which uses the model. All this would be version 2, which should be quite interesting.

took a break, got to think about some things

Took the day off and crashed. Work this week and next on COODBMS will be a bit irregular as we are moving to Raipur. And that's a very long train trip.

I've been thinking about levels of an application. At the level where browse operates, all rolons are just variations on a theme. So it is dumb and stupid and can operate on the structures of any application.

Taking access control as a sample application, clearly there are (at the application level) different kinds of rolons with constraints about where they can be found, relationships, etc. Now obviously we can build up some meta data for all this and use this at the UI level to both impose the constraints and assist the user in defining appropriate requests. I'm just wondering if there is more to it than that.

o With 10 more commands, branch access control is now fully configurable with Browse.

o New WellKnownOperations group.o

5 more wiki pages in the docs.

o 1 bug fixed in setWellKnownName.

http://agilewiki.wiki.sourceforge.net/COODBMS

http://sourceforge.net/project/showfiles.php?group_id=106672&package_id=258830

COODBMS release 0.11.6

o New utility, PurgeHistory, can be used to limit the amount of history retained in a branch.
o Timestamps are now in the format yyyy.MM.dd-HH:mm:ss-SSS. This allows transaction history to be queried for any time period.
o Browse now supports 3 more commands.
o Web pages have been updated to reflect these changes.
o New web page on journals.

COODBMS release 0.11.5

o 2 CowDb bug fixes,
o Elements with work attributes now persisted correctly,
o Backlinks command fixed,
o User account journal now reflects all user updates,
o Links, Rtree and Up queries added, and
o Account creation commands added.

CowDb release 3.3.3

release 3.3.3:

Bug found/fixed: The add operation on an ordered node was not removing the old name. Consequently an iterator would encounter the same name in more than one location.

Database names must now end in ".cowdb".

more browse commands, more documentation

The commands links and rtree have been added to browse and the COODBMS page has been updated to illustrate the use of these commands.

The createMasterAccount has also been added to browse.

COODBMS release 0.11.4

o Added selections to the UI of Browse--less typing is now required to use it.

o Added elements, children and parents queries to browse.

o The COODBMS home page now contains a lot more information on how to use browse as well as discussion about the initial contents of a branch.

Download: http://sourceforge.net/project/showfiles.php?group_id=106672&package_id=258830

finally, some serious writing

The elements, children and parents queries have now been added to the browse program. That done, I spent some time writing about the browse program and explaining the content held by COODBMS. And it looks to me that I'm off to a great start. I hope you enjoy reading it as much as I did writing it.

selectors and default commands, release 1.0

Spent the day in the hospital. Rupali had her eye operation--an apparent success, though it will take 2 days for her vision to clear.

Worked on the COODBMS documentation while at the hospital. I also worked up a todo list of things that need to be done before we can call COODBMS done.

Rupali and I were dead tired on our return, but I did manage to enhance the Browse user interface. Now for example if you enter the databases command, it numbers the list of databases. If then you enter the number of one of those databases, the database command is executed with that selection.

Why spend time on browse? Isn't it just a learning tool? Well, I was thinking about that today too. We're going to need a configuration tool and there is no reason why browse can't be extended to handle that. So a minor enhancement to the user interface (it was just too awkward as it was) is well justified to make it more usable.

My concern here is that for COODBMS to be a success, we will need to get folk using it. Having good tools is helpful, but we need those samples just as much. Hmm. That is one road to success at least. Another possibility is putting a great wiki on top of it. But I'm not known for writing great GUIs. Success then, one way or another, means building up a team of dedicated developers. But for that we need a really good value proposition. COODBMS is just too different to be adopted quickly or easily. It is a long path. But it always is when you're talking about radically new technology. And programmers are always a hard sell. Sigh!

coodbms browse

COODBMS release 0.11.3 should be quite helpful when it comes to learning RoleML. The browse program is a non-graphical user interface which now supports several queries, allowing you to navigate databases, branches and content. It also has an option for viewing the request/response documents, which could be handy if you are working on a program which will use COODBMS.

release 0.11.3:
-New utility, listUsers, lists all the children of /USERS.
-New browse command, show, displays the selected element and all subordinates in RoleML.
-New browse command, protocol, toggles the display of the RoleML requests and responses.
-Bug found/fixed: Queries against a new master.cowdb trunk were failing.
-New browse command, wellknown, lists the well known rolons.
-New browse command, go, is used to navigate the database. It takes a pathname (absolute, relative or rolon relative) as an argument.
-New browse command, tree, lists subordinate rolons.
-New browse command, backlinks, lists all references to the selected element.
-Server and client now include the standard XML header line on all generated XML documents.

docs, browser

The browser is pretty much done now. I still want to add a keyword command, but that can wait until the keyword sample gets converted.

http://agilewiki.wiki.sourceforge.net/COODBMS

I've also started working on reworking the documentation. Catch the link above.

The evening's progress

I am happy to report that the ListUsers utility is done. This then completes the set of utilities for managing accounts and completes as well the utilities needed by COODBMS administrators. In the process I also implemented a listChildren operation which will have considerable general utility.

I've also added two very handy commands to browse: show and protocol. The show command displays the currently selected element and all subordinate elements using RoleML. And the protocol command toggles the display of the RoleML requests/responses to/from the server.

I'll note that the intended audience of browse is developers. For while browse lets you see the data (which is helpful for everyone), it should prove helpful for developers trying to figure out how to write and process RoleML. And the protocol command in particular should be quite helpful for that.

Current state, future intentions

Database Management

A comprehensive set of utilities have been released for managing COODBMS databases and branches.


Account Management

The utilities for managing accounts are lacking only the capability of listing the accounts. This should be completed and released by Monday.


Browsing

A database browser has been released, but it is hardly begun. It currently only allows you to list/select databases and branches, and to login. The intention is to complete this next week.

coodbms release 0.11.2

release 0.11.2:
o Added the necessary hooks to ServerMain, SocketHandler and CoodbmsFactory for extensibility.
o The server now supports RoleML queries and transactions.
o The listBranches utility no longer requires a password.
o New utilities: listDbs, createMasterAccount, createAccount and setPassword.
o New operation, context, returns the current context.
o New Browser client supports the following: help, exit, login, databases, selectDb, branches, selectBranch.

client/server architecture, browser client

The client/server architecture is now done and I've moved on to working on a database browser with a simple non-graphical user interface. Hopefully I can finish this over the weekend.

After that I figure I need to work up an extensible console which does a lot more than just browsing. This will require the addition of more metadata to the databases. After that we call COODBMS done and move on to namespace management.

Once namespace management is in place it will be a good time to work on the wiki. And yes, there is a connection. Without namespace management (things like import static /include) we are stuck with either flat wick's or dis-functional hierarchical wikis. Namespace management is the missing piece.

COODBMS release 0.11.1, future plans

o When run in server mode, COODBMS now has a comprehensive suite of client utilities for managing its databases.
o Databases can now be individually configured using property files.
o Client/server partially implemented uses XML over sockets.
o Error handling has been added.

Work Planned:
Server support for RoleML queries and transactions.
Simple client which executes pre-defined RoleML documents with limited substitution.
A browser client supporting the list well known, tree and Xpress operations.
Inter-navigational methods for the client DRM.
RoleML composition methods for the client DRM.
Notifications.

CowDb release 3.3.2

release 3.3.2:
Common has been folded into the CowDb jar file.

DefaultConfiguration class has been renamed to DatabaseConfiguration and, if passed the name of a database file, tries loading a .cfg properties file by the same name. Failing that, it attempts to load the default.cfg file.

DbProcessor instances were not added to a global map, resulting in duplicates for the same database and also lost file handles.

As a close operation needs to wait for current processing to complete (it is graceful), additional logic was needed to prevent a db from being opened while it was in process of being closed.

good progress on client utilities, next steps

Well I'm a bit happier now about error and exception handling. Wrote a bunch of client-side utilities and found/fixed two CowDb bugs in the process--it is always helpful when you have queries (like listOpenDbs in this case) that allow you to see what's happening.

Still a few more client-side utilities to go yet. And I must say, it is nice having bat scripts now for startup, shutdown, listOpenDbs, closeDb, blockUpdates, unblockUpdates and createBranch. I'll include them in the next release as well.

So it looks like COODBMS will be completed this week. Then a small quandry--do I work on a wiki interface or proceed with namespaces? My concern here is that there are so many bad wikis out there, and I think I can create a very interesting one once I've got namespaces implemented. So I'm inclined to proceed with namespaces rather than do another boring wiki.

On the other hand, having a user interface to COODBMS would be very helpful. Without it I can only do some batch demos. Of course, focusing on those demos would be a very fine thing. With the client/server architecture it will be easy to put together some nice test cases for looking at speed and loading issues. And once the client/server architecture is fully in place, there are all those CowDb tests and COODBMS samples to convert. What we don't have right now are some good tests dealing with masses of data.

Hmm. Looks like I should be spending April on testing COODBMS. That's the problem with creating real product--it takes so long to get to the fun stuff. Like inferencing!

extending the client model

I've been thinking about how best to extend the client model while retaining and adding clarity to the code and I believe the best approach would be by layers of subclasses. We've got a good start on a reasonably simple ModelObject.

The second layer would be to define classes like Rolon, Unit, JUnit, etc. Here we could define the inter-rolon navigational methods. The third layer then would add the RoleML compositional methods.

But today I want to focus on a set of simple administrative utilities, robustness, exception handling and all.

it works now, sortof

We've now got a client-side binder for the new client-drm. And we're now processing responses from the server.

Now I've jsut been working on the client block utility, nothing really interesting or very usable. Tomorrow I've got to make it more robust and then convert it to a base class (it IS only one small class) and crank out the full set of client utilities: block, unblock, create branch, fork branch, et al. Once that's in shape I can turn my attention to transaction and query processing.

The good news is that it is a very light-weight client. I've only got 3 small classes so far: BlockUpdates, ObjectModel and Binder. And that's very cool. Of course, things are a bit incomplete here and there. But I don't think that the client will grow very much even so. Hey, the client jar is only 51KB right now, including base64, and requires no other jar files.

Well, there is one big thing that needs to be addressed--RoleML scripting. That's a bunch of code that needs to be added to ObjectModel. But I'm studiously ignoring it until we have a working set of utilities.

Hacking out a lot of code

Well, I now have a ModelObject class in client which serves as a simple model, as well as an Xpress class. So I am able to send a request to the server and process it. Just. But to handle a response, I'm also going to need a binder in the client. More code to hack out.

As for quality, it is very rough. But I figure it is important to get something working first. Then I can worry about exceptions and errors. Lots of fun getting this stuf working, yes. But I'll pay the price later, so I am not completely happy with this process. At least the new code is confined to new classes--I'm not messing with any existing functionality. So it isn't really so bad. (Or so I keep telling myself!)

The client DRM is, at least at this point, very simple and light-weight. Hopefully I can keep it that way, as this code will need to be ported to other languages and adopted to a number of different mid-tier systems, each with their own requirements. So I'm avoiding anything fancy. Even integrety checks are minimal--they can involve a lot of code and a lot of code is exactly what needs to be avoided here.

Another reason for keeping the client side as light-weight and clear as possible is because I expect that the client code is what folk will be looking at first. And that may well be a very diverse audience.

basic client/server is working

As far as it goes, the client/server architecture is now working, including a graceful socket close handshake. The holdup at this point now is the lack of a client DRM, so that now is my focus.

a top-down approach

It occurs to me that a top-down approach would be interesting and helpful. So even before the client DRM is done we could start with programs to block/unblock updates. (These utilities allow for backups of databases without interfering with queries to the blocked database.)

less is more

I'm thinking now that the classic server architecture might be best. We eliminate the queues and we eliminate the problems. We eliminate the thread pools (except for servicing socketts) and we minimize the overhead per sockett. A smart client then can maintain a pool of idle socketts and a dumb one can just open new ones as needed. We also reduce the number of potential bugs and speed development. And for notifications, a client interested in them can open a sockett to receive them.

The only special requirement in this case is that a smart client pass the same client id on all socketts so that a login token created on one sockett will work on the others.

client/server architecture for COODBMS

OK, we now have optional .cfg files for configuring databases, and even provision for defaultDatabase.cfg when there is no .cfg file specific to a new database. Common is now part of the CowDb jar file. DRM is now part of the COODBMS jar file. And I'll start work on the client-side DRM tomorrow morning. Time to speculate about the client/server architecture.

As CowDb already supports an advanced threading model, we need to take care to realize the potential of this threading model in the new architecture. I am also concerned that most databases seem designed to support 2-tier architecture and not 3-tier. I.E. You need to dedicate a client thread for each parallel database access. Not a good thing, especially for fully asynchronous web servers which otherwise manage very well with a single thread, e.g. Python Twisted.

So lets say that we will have one (or more) socketts for each client, but each sockett is fully asynchronous and bi-directional. A client then can pump a series of requests for different users through a single socket and process the responses as they arrive. OK, then each request needs to be tagged and the response needs to carry that same tag. However, we will not make any promises about the order in which the responses are returned. Simple clients then can treat the socketts as if they were synchronous, waiting for a response before sending the next request. Clients serving multiple users should generally wait for a response before sending another request from the same user, but that is strictly a client issue.

Implementing this should not be too difficult. We dedicate two threads per sockett--one for reading and another for writing. There can be a single ArrayBlockingQueue per open database to which all the sockett reader threads will put the requests they have received for each database. For each sockett there will be a ConcurrentLinkedQueue which will provide the responses for the sockett writer threads. Further, requests placed in the ArrayBlockingQueues must carry a reference to the ConcurrentLinkedQueue to which the response is to be returned. Executors.newFixedThreadPools can then be used to service the requests read from the ArrayBlockingQueues, with the number of threads allocated for servicing a database being configurable for each database.

We can create the ArrayBlockingQueues and thread pools dynamically as requests for previously unopened databases are received. Conversly, as databases become idle we can free up these resources as well.

The expectation here is that the number of clients will be small, trusted, local to the database server, and long-running. I.E. We are targeting a 3-tier system rather than 2-tier.

One of the considerations that this design addresses is that a given database can only service one update request at a time. So we don't want too many threads ending up servicing the same popular database and consequently blocking access to other, less popular databases. One design issue then is the action to be taken when an ArrayBlockingQueue handling the service requests for a particular database becomes full. If the sockett reader thread waits for space in the queue, then the client can not submit requests on that socket for other databases. But we do not want to dedicate a sockett per database per client.

One answer is to make the ArrayBlockingQueue moderately large and to have clients manage the number of outstanding requests for any given database. Having flow control at the source helps avoid congestion, so long as the number of outstanding requests allowed is large enough to maximize throughput.

Another thing we can do is to have a seperate ArrayBlockingQueue and thread pool for each database X client. Now these resources can be freed when there have not been any requests for a given database from a given client for some time. And a database would be closed only when all of its ArrayBlockingQueues have been closed. And with different sets of ArrayBlockingQueues for each client, only the misbehaving client will suffer congestion problems. Of course, a client can choose to have multiple sockett connections to the database server as well.

getting ready for client/server architecture

There are a few things that need doing to get things ready for converting COODBMS over to client/server.

First, I am thinking that none of the existing code will be included on the server side. The DRM has some complicating factors because it needs to run in the server and I believe it is important to keep the client-side as clear as possible, expecially if we are going to have clients written in multiple languages. So I see a need to write client-side DRM classes which are independent of the existing classes.

So if we are starting almost from scratch on the client side, the first thing is to reduce the number of jar files. Common can be folded into CowDb and the existing DRM can be folded into COODBMS. The second thing then is a specialized client-side DRM.

The third item is to address configuration. The current mechanism is fine for CowDB, but simply will not do for a COODBMS server. We need to be able to specify the configuration of various databases without code changes now. So we need to use files. Let's establish a name convention where for a given database file we have the option of having a configuration file. Failing that, we can use a common configuration file. And failing that we can use the default configuration. That should give us enough flexibility while minimizing operational requirements.

None of this should take very long. Then we can start getting serious about client/server.

COODBMS news

https://sourceforge.net/forum/forum.php?forum_id=796194

COODBMS release 0.11

With the addition of the listWellKnow and tree queries, COODBMS now has a minimum workable set of queries--see sample 22 for details.

Write access control is the final piece in the access control capability. Access control is fast, scalable, extensible and simple, working at the operation and Rolon level. Write access to a Rolon can be disallowed or restricted to a single user or user group. Journals can not be updated directly, providing a reliable audit trail; configuration data updates are restricted to the AdminGroup; and user account updates are restricted to the account owner.

a productive evening--scalability issue, write access control

Write access control is nearly complete. Got a tad sidetracked--I'm reworking OpCode access control to make is fully scaleable to any number of users. But that is almost done and there is likely not much left to write access control.

queries--it is time

We now have a moderate amount of access control data which is generated when a database is initialized and no effective means of displaying it. The queries that we have are simply too verbose--I had to chop them out of the sample programs when I updated them to work with access control. Also, the existing queries (except for express) use a print stream, and that will not be supported when we go to client/server architecture. So right now, queries should have priority.

Two very basic queries which would help a great deal would be (1) list the pathnames of the well known rolons and (2) display the pathnames of the tree of rolons under a given rolon. These two queries, together with express, would go a long way to making the content of the database (ark) visible. And of course, these new queries should return a result (text entry) rather than using a print stream.

I must say, this is the perfect time to implement these queries as we now have some interesting data to run these queries against.

coodbms 0.10.2: operation access control

Operation access control is now in place, providing different sets of operations to different groups of users. Fully configurable and extensible, you can define new operations, operation sets and user groups. The initial configuration allows guests to create their own accounts and for admins to set the passwords for other accounts. Logins are controled by a single database and tokens are issued for subsequent access and for access to other databases on the same server.

read/write access control, progress

Access control for operations is done, though only 5 of 25 samples have been completed. I expect to wrap it up tomorrow and then on to read/write access control.

Read/write will be a tad simpler to implement. Each operation gets an attribute which flags it as reading its context, updating its context or none. (None being no access to its context at all--as in the case of a login command.) Then we introduce an optional AccessControl DSec. Each section under the AccessControl DSec will indicate (via attributes) a user or user group name and the permitted access. Read/write access control then is only active when there is an AccessControl DSec.

Now of course we will want to add an AccessControl DSec to all the access control structures we've created--with write access for AdminGroup and read access for GuestGroup (which everyone is a member of).

We will also want an AccessControl DSec added to every user rolon, giving write access only to the owner.

Once all this is done we can move on to client/server architecture. Though we may want to take some time out to do a few queries. With all the access control structures, we've got pleanty of test data to exercise queries against, finally.

coodbms0.10.1, next steps

COODBMS release 0.10.1:

• RoleML has been extended to support account creation, login/logoff and password management.
• Passwords have been secured.
• A new exit method allows an operation to return an error result and exit the script rather than having to throw an exception.

This is just the preliminary work for access control. The next step will be to control access to various operations. For example, not everyone should be able to change another user's password. After that we can worry about read/write access.

account creation

http://agilewiki.wiki.sourceforge.net/AccountCreation

Good progress today--got account creation working and wrote the guide. (See the link above.)

The code got interesting. The createAccount operation required that, in the middle of processing a transaction on one database, a query must be run against the master database. It went fine, but I've got a feeling that we need to have some means of returning an error message.

I also ran into some problems doing a query. The culprit was immutable name which now works in a query so long as the name was already immutable.

Now what I am particularly happy about is that the new code is making good use of a lot of COODBMS features. So a lot more code is being exercised. And the few problems coming up are very minor.

Passwords should not be in a regular branch

If passwords are kept in a branch, then there will be much confusion when rolling back to an eariler branch. Similarly it makes no sense to have account ledgers in every branch or database, as a user needs to be able to review a consolidated ledger--and all logins should be against a single master account. At the same time, users should have a user rolon in every branch they are active in--permissions may differ and for each branch we should be able to view the activities of each user.

So let us say that there is a master branch in a master database where the master accounts are maintained--which contain the account ledger, the password and little else. One logs into the master db and gets a token, which can then be used without subsequent access to the master db as the server will maintain the valid tokens in memory.

A user then needs a master account before they can have an account in another database or branch.

New guide

http://agilewiki.wiki.sourceforge.net/RolemlQueries

Above is the link to the programming guide for RoleML Queries.

access control, queries and security

Access control will be at the level of rolons and operations (opcodes). User groups and operation groups will also be supported. But as queries will often span multiple rolons, these will wait until access control is in place--otherwise they would need to be redone.

The consideration of most security aspects will be delayed until later. Mostly I expect this will be handled by AgileWiki clients, e.g. in an applet. Multiple clients will be supported, but clients should support multiple users. Clients will be trusted but must have a fixed IP address. (The client IP address will typically be the IP address where the server is running.)

One consideration here is the need to support multiple programming languages. Having good crypto between the client/server slows things down at a critical point but may also restrict the choice of client programming language.

Now the first point of contact for the user (except for guest access) is account creation. We can allow for both self creation and for creation by an authorized user. Access control should be configurable to restrict these operations as needed.

We will want a journal of all user transactions. This will require a small change to the RoleML interpreter. Note that changes to a journal will need to be restricted.

And like the check register application which keeps a ledger of the checks processed, there needs to be a ledger of user login/logoff (token creation/destruction).

beta release: COODBMS 0.10

The new RoleML interpreter is in place and now fully supports queries. See sample 22 for a simple example.

good progress on RoleML-based queries

Got all the easy stuff done today, including a new QTransaction class. What remains is to create an executable pluging for descriptor elements and migrate the existing code the new form. The plugin will be a bit different from Apps, as it needs to work with both Descriptor elements and Descriptor Model elements. Of course, after that we need to implement some basic queries.

Oh yes, one item of interest. Model elements can't resolve pathnames. And for cases where there is no context, then we also need a Rolon to serve as the default context. Well, there's only one Rolon which is always there when you need it--Keywords. So the Keywords rolon is used to resove pathnames and to serve as a default context (i.e. its eval method gets invoked) when there is no other context. A bit of a cludge, but it shouldn't make for too many complications down the road.

preliminary design for queries

The problem we face is that, where now we are using DSecs and DEnts in the interpreter, for queries we will be using DSec and DEnt model classes. So either the executable code on DSecs and DEnts needs to be duplicated on the model classes, or the code needs to be relocated. Now I've got nothing against duplicating the code, so long as it is minimal. But for the bulk of the code, we need to relocate it.

Generic code can be moved to the transaction. We create a new RTransaction class which JTransaction (and then QTransaction) will then subclass. That's the easy part, and I almost always do the easy part first as that often clarifies what remains. (You often learn something, or at least become more familiar with things, by doing the easy part first. Doing preliminary designs is also helpful.)

As for the non-generic code, we've been putting that in App classes. Instead, we need to create an extension which can be included in the composition of both the Descriptor elements and the descriptor model elements. This will be phase 2.

The third phase then is to implement RoleML-based queries. As usual, I prefer to put off the actual implementation until it has become trivial. (This never fails to drive my managers and coworkers crazy.)

future plans

I've got 3 things on the list for COODBMS:

1. Convert queries to use RoleML. This project will begin with a rework (more code cleanup!!!) of JTransaction.
2. Access Control. (A rewrite of AgileWiki3's access control)
3. Client/Server via socketts.

I suspect that I'll move COODBMS to beta once we have RoleML based queries, as Access Control in many ways is an application.

Now are socketts the right kind of client/server? I'll note that AgileWiki3 used RMI, but this causes problems for non-Java clients. And as everything will be passed over the socketts as XML documents, RMI just adds extra overhead. Another advantage of not using RMI is that we can then have callbacks/notifications. I'm thinking that advanced clients would have a cash of rolons and the server could send notifications when a rolon "of interest" is updated... Just a thought for now.

coodbms release 0.9.4

This release wraps up the common API and DRM cleanup:

• DRM factory now throws an exception when an unrecognized role is encountered.
• The DRM factory now works more like the CowDb factory when creating handles.
• DRM now uses the [more extensible] common eXpress logic.
• DRM handles ENTs the same way CowDb does.
• Setting the name or well known name now results in a call to the appropriate method in both the DRM and CowDb.
• The setMyName DRM method now checks for the prior use of the same name in the owner element.

cowdb release 3.3.1

release 3.3.1:
o Bug fix: Serialized objects held by an Entry were not being cloned--the reference was shared.
o EXpress has been moved to common.
o The common portion of Display has been moved to common.
o Element is now PElement for consistency with PHandle.

Javadocs are on-line: http://agilewiki.sourceforge.net/

finally moving forward

The common API has [finally!] been wrapped up and today I was able to focus on the DRM. The DRM is now also in good shape. Tomorrow I plan to work on a bit of general cleanup relating to attributes. (I want to catch attributes being set which have side-effects, like the name attribute.) After that it is, at long last, on to working on query scripts.

Now that was a whole lot of time spent on the common API, but I believe the effort has brought some [necessary] clarity.

coodbms 0.9.3

release 0.9.3:

The results of a JTransaction is now a RolonModel. Responses now are ledger sections in the results rolon.

Common, DRM and COODBMS inheritance reworked to be much closer.

Only CSecs can now have pathname references.