javadocs updated

As I said before, the client-side API for the DRM is done. Updated javadocs have now been posted. Only the inheritance model needs work.

Finished up the common API

I'm very glad to be finished with the common API for now. I'll just note that this is the client API for the DRM, though the methods apply to COODBMS's RolonicElements and many of the methods also apply to the CowDb handles and elements.

However, there are now several changes that I am aware of that need to be made to the model. So I expect to be working on the model tomorrow.

coodbms0.9.2, updated javadocs

release 0.9.2:
CNode renamed to RolonicElement.
DRM has been flushed out.

Javadocs have been uploaded to http://agilewiki.sourceforge.net/

API refinements, DRM developments

Took most of the day off, but still managed to get some good work done this evening.

In the common package, two new interfaces have been added: IRolonicElement and IEntry. And in the DRM, I've now added SectionModel, EntryModel, ChildrenModel and MyKeywordsModel. I also dropped a number of inappropriate methods from the common interfaces and added a number of missing methods to the DRM.

I figure another day of API cleanups and then another day or two of documentation and then I can finally get back to working on queries and RoleML script.

latest javadoc posted

http://agilewiki.sourceforge.net/

Took the morning off. So finally now I've posted the [complete] javadoc for your reading pleasure.

API cleanup & documentation

I've started documenting more now, which is slowing things down. But when working on API, speed is not a consideration. So while documenting the API in the common package I'm doing the deep thinking necessary for the creation of a usable API.

Now I've found the Elementinterface to be to big to be anything but ugly, so I've started breaking it into more managable chunks. I've already spun off IAttributes and IEntry.

There is now a package javadoc for the common package, and I've finished the javadocs for ICommonObject, IAttributes and IEntry. I expect to upload the updated javadocs tomorrow.

on-line access to javadocs

http://agilewiki.sourceforge.net/org/agilewiki/package-summary.html

As I plan to do more writing in the javadocs, I figured it might be good to put them on-line. The above is a link to the intro to agile wiki which I included in today's release.

cowdb 3.3

release 3.3:
o Wrote the javadoc for the org.agilewiki package.
o The common package has been reorganized and cleaned up.
o Node has been renamed as Element for consistency with ICommonElement and ElementModel.
o Attribute Apps had a name clash with attributes and have been renamed Entry Apps, which is consistent with Rolonic terminology.

another productive day

Spent the day polishing the common API. The javadoc really needs work now and I expect to get to that in a day or two.

Spent the evening flushing out the DRM and cranked out a lot of code. Navigation methods are in place, pathname, make, etc. Also created classes for UnitModel, JuModel and HandleModel. I am thinking now that ENTs should work the same as in CowDb, so I'm going to stay with the DRM for a bit longer. I am happy to see the DRM coming along so nicely, but at the same time I'll be happy to be able to move on to other things--in and of itself it is not the most exciting thing to be working on, though there are a number of exciting things that can be done with it as it will be capable of modeling Rolons as well as collectons of Rolons.

The names have been changed to protect the innocent

I am very much behind on my writing and it is about time that I give it the appropriate focus/effort. I'll start once I've spent a bit more time with the DRM. But before beginning, some of the names used in the code need to be changed. Indeed, the worst offenders are the app attributes, which are really not attributes at all. (And all the worse because we already have real attributes and this is just too confusing.) So the attribute apps have been renamed to entry apps--which is consistent with Rolonic nominclature.

The other area that needed to be addressed was elements/nodes. In the common package we have elements and in the DRM we have element models. So for consistency, the CowDb Node class has been renamed to be Element and the COODBMS CNode has become RolonicElement.

My appologies to everyone who has been following the development of AgileWiki, but I believe these changes will be helpful for newbies. (And aren't we all really just newbies at this point?) I believe these changes will also make it much easier to explain the code/concepts to others.

COODBMS Release 0.9.1

release 0.9.1:
o Reworked the DRM methods to override existing methods on Comon Object.
o Display now works with the DRM--see Sample #17.

common, DRM, a good API in the making

Big day today--cleaned up common. ICommonObject now has two sub-interfaces: ICommonElement and ICommonHandle. And a lot of spurious methods have been removed. Common is now the basic API for AgileWiki, though I still need to spend some time on the javadocs.

Tonight I also found some time to extend the DRM a bit. One small milestone achieved: Display now works with the DRM. Its a good start anyways, though there's still pleanty of work left to do here before going on to queries.

Overall I am delighted with how the common package is turning out. Interfaces usually drive me nuts, with either too many internal methods, too much casting when using them, or both. But I finally got it right. These are clean interfaces, and easy to use with very little casting. The final determining factor for acceptance then will be the quality of the javadocs. This is well worth the time spent, as a good API is critical. Indeed, there is nothing harder than creating an API that is good enough to be acceptable by other programmers. Too many otherwise great projects fail because the API stinks.

cowdb 3.2

CommonObject and Base64 have been moved to a "common" jar file, allowing their use without any extra bagage. (COODBMS's Document Rolon Model has no other dependencies.) This is a first small step to separate client/server processes.

common object, drm

The new CommonObject is a bit strange, but I've been working with the code and I really like it. At the highest level, you are just working with common objects and handles. And you can do a whole lot with just that. There are times when you need some additional capabilities, and only then do you need to do any casting.

One concern I've had is that it may be difficult figuring out why when you call a method in one place it works (COODBMS) and in another palace (CowDb code) it doesn't. So I've now updated all those UnsupportedOperationExceptions in CommonObject to report the name of the class which is not supporting the operation. Then you can access the class and see what is actually supported. Another thing I'll do is to leave the javadocs for ICommonObject untouched and modify the method javadocs in CommonObject with a description of unsupported. Then you can access the method from a particular class in the javadoc and it will either describe the method or say that it is unsupported. Should help some.

I've also started work on the DRM/ElementModel and it really needs to be flushed out. I've changed a few of the method names to match CommonObject where the method is equivalent. Next I plan on modifing the remaining methods to work like the methods on CommonObject. But really there are a lot of methods that just need to be added. For one thing, the HandleModel class isn't even written yet.

coodbms 0.9

release 0.9:

Added eXpress, bind and bindRolon opcode processing to CNode.

Added eXpress, bind and bindRolon methods to DoModel.

Bind now fully supports keywords and children. Prior to a bind, the parents CSec must be removed.

Document Rolon Model is now a separate jar file, a first small step towards client/server.

Methods on the DRM which add actions to RoleML script now end in "_" to distinguish them from other, similarly named methods.

New API--Common Object--sports many of the methods of PObject, PNode and CNode.

API cleanup

I'm 1/4th done a major API cleanup.

First, there's just too much casting happening. By adding a bunch of methods which throw UnsupportedOperationException to CommonObject this can be avoided. But avoiding casting is not the major benifit. As the DRM also extends CommonObject, we need only use the same method signatures for Rolonic Element classes and ElementModel classes and we've significantly reduced the size of the API.

Second, by also providing a ICommonObject interface we can then have common interfaces for classes like Rolon and RolonModel. This will help a great deal when extending the RoleML script to work with queries.

But gosh, it is a lot of work, even with a good IDE. I've almost completed refactoring CowDB, but there's still some work left and I've not yet had a chance to test it.

action_ method notation

Previously, DRM was intended only for creating scripts. So methods which dealt with navigating or editing the model began with "m" to distinguish them from actions being added to the script.

With DRM being reintended for more general use and sharing greater API comonality with persistent objects, we need to drop the "m". So to distinguish betwee setting a headline on the model and compiling a set headline action, action compilation methods will now end with "_".

client/server

At some point we will want to implement COODBMS as client/server, where both client and server processes make use of the element model. This should be a very fast system if we can take full advantage of RoleML script, with a lot of work being done by each transaction. (Transactions having high overhead.) Note also that each transaction will consist of a single request from the client and a single response from the server--which will make it very fast indeed!

To this end, the Document Rolon Model has been broken out as a separate jar file--we will not want to include the server code on the client side. The expectation here is that the client itself will be very light weight.

CowDb release 3.1.1

release 3.1.1:
o Name is now persisted as an attribute--otherwise problems with round trips.
o Symbolic references are now expressed in XML as text content rather than as an attribute--again, to avoid round-trip issues.
o The factory now sports the String eXpress(PNode node) method for expressing nodes as XML.
o Bug fix: Xpress was displaying too many handles. Now its output is similar to Display--only handles with symbolic references are displayed.
o Bind now supports well known names.

bind, queries

Complete round trips are now fully supported: Rolon -> RoleML -> DRM -> RoleML -> Rolon. So you can copy things out of the database, use DRM to edit them, and then use the results to create new Rolons. Still need to write a guide, but other than that it is done--with 3 sample programs.

The next step is to modify the way eval works to support queries. At the same time I expect to be able to support having one DSec execute another and then process the results. This seems like a reasonable capability to have, especially once you move past trivial examples.

coodb0.8.1

release 0.8.1:
The create method for model elements now models the create method for Nodes.
A common object now handles all attribute processing.
RoleML -> DRM bindings.
Name is now an attribute--otherwise problems with round trips.
Symbolic references are now expressed as text content--avoids round-trip issues.

all done

The name problem has been handled. The common object now manages both the name and the immutableName flag. I've also fixed handle now so that symbolic references are expressed in XML as text content to avoid a round-trip issue similar to the one I saw with name.

Tomorrow then I need to start work on the remaining round-trip issues, like more testing. (The CowDb sample 0 only goes so far!) Of course for that, I need to add to RoleML so that we can return a Rolon as RoleML in a response.

XmlModelBinder, names, symbolic links

The XML Model Binder is now done. In the process, I realized that there will be round trip (Rolon => RoleML => Rolon) problems with the current implementation of name in Persistent Object. I'm not impressed. There's also a really big hole--handle bindings.

So I'll work on fixing the problem with name. Then work up a sample of simple round-tripping, which will include a query written as a JTransaction. (We'll fix that later.) And then spend some time on handles, which should include parents, children and keywords. This will finish the XML portion for a while. (We'll need XML script for creating branches and things like that--but that will come much later.)

Once we put XML to bed (for at least an extended nap!), we will be in very good shape to work on queries. And completing Queries will put COODBMS back to Beta. THEN we can look at ACLs. (Yes, AgileWiki3 had ACLs. We still have a long road ahead, though this implementation has many advantages over AW3. It is just going to take a lot of time and effort. Stay tuned.)

cowdb3.1

CowDb release 3.1:
The test suite was not updated in 3.0.3--the static includes were left out.
The order of the eval method's arguments was inconsistent.
A common object now handles all attribute processing.

CommonObject handles attributes

Lots o refactoring this afternoon and evening. CommonObject now handles attributes and role, whereas before there were 3 different ways attributes were handled. I've tested everything at least once, but not with all the changes. Tomorrow I'll test more carefully and then do the releases.

The code changes will be quite helpful when queries are revamped. But at this point I need to review the new code base. Should display/xPress/XmlBinder work with both persistent objects and the DRM? I'm thinking no at this point, which means that I'll soon write some binder code for the DRM.

ElementModel factory, CommonObject class

OK, the create method for model elements now models the create element for Rolonic Elements, which is goodness. Indeed, if you now look at the check register you will see that we are able to use the same model class, ActionModel, to model two different Rolonic Elements. And we are ready for DRM binding, only that project will be delayed a bit...

I'll note that as the DRM matures we are having more and more duplicate code. And while the JTransaction interprets the DU of the Transaction Rolon, when we implement the equivalent capability for Query we will need instead to interpret a model DU instead. Not good. So it is time to create a CommonObject class which will be the base class for both PersistentObject and ElementModel. And that should keep me busy for a while. Hopefully the result will make COODBMS a lot easier to learn, though it means a lot of changes to CowDb.

progress on the DRM

Spent the evening refactoring the Document Rolon Model. The factory now instantiates ElementModel when it doesn't recognize the role, which is great for modeling. The next step will be to drop those subclasses which simply contain constructors and then to modify the plugin method in the factory to associate a model element class with every role. I expect to be able to do all this tomorrow morning.

That then lays the necessary groundwork for XML => DRM binding which I might be able to complete tomorrow as well.

The Document Rolon Model (DRM)

After the release this morning I took some time off and just watched tv. Taking time off is always difficult--I get bored before I've really had enough of a break to come back to AgileWiki fully recharged. Rupali spent the day running errands so I had an especially quiet day. Time to reflect a bit, but not really enough time away from it all.

I see the the DRM now playing a larger role now, but the code just isn't there. For example, there is currently a 1-1 mapping between roles and subclasses of ElementModel and that is pretty restrictive. Overall the methods are pretty restrictive. That's a good thing in a scripting language, but not so good in a modeling tool. I also see a need for the factory to handle element instantiation the same way it handles persistent object instantiation--you give the factory a role and it returns an object. This will be very helpful when binding XML => DRM.

From the above, you may be thinking that I'm getting ready to make the database an independent process. You would be right, but there are bunches of things to be done before that. Like implementing ACLs--which is also a ways away.

coodbms0.8

release 0.8:
Reorganized the constants; replaced implements with static include. The javadocs look a lot better as a result.
The order of the eval method's arguments was inconsistent.
JTransaction now returns a DRM with a collection of responses from the actions which have been executed.
A sample application, a check register, has been implemented. Process check returns the new balance.
A guide has been writen for the check register.

Process check now returns a result

It may be a bit rough, but we now have a reasonable mechanism for returning results. And the check register illustrates this. Guess we really need that guide for the next release.

Tired and going to bed. :-)

responses

At this point there is a big hole in COODBMS--responses. To date we've been using out, which should only be used for debugging.

Every action potentially can have a response. We also need to rework queries to use RoleML and have a similar mechanism for responses.

We can use the DRM for responses, adding to this model as needed to handle various types of responses. The top level of the responses will be the Responses element. Each action will have a responseId which will, when there is a response to that action, be used to name a element under the Responses element.

With this approach we will have the option of running COWDB as a separate process with multiple clients, passing the responses back to the client as XML.

Progress on Check Register sample COODBMS application

The check register is to the point where it can process checks, which is to say it is hardly started but what is done is working if not very usable. But even a fragment of an application is very helpful in developing COODBMS.

Case in point, the transaction to process a check contains an action DEnt which contains all the necessary data (payto, amount, date, etc.) but no application logic. Actions get evaluated by the target object. So where do we put the check processing logic in the check register rolon? In a DSec of course!

Now TRolons always have a main DSec with an execute method that gets called to process the transaction. Similarly, a rolon can have an Eval DSec which evaluates actions with otherwise unrecognized opcodes. This Eval DSec has an eval method and when it is called it in turn calls the eval method on all subordinate descriptor nodes successively until the action is processed. So we can extend the capabilities of a rolon just by adding DEnts to the Eval DSec. And it is precisely this kind of composability which is what Rolonics is all about.

At this point the priority is to continue to work on the check register application and to polish the API a bit to make the application code a bit less awkward to write. Hmm. I think I need to work up a guide as well.

cowdb3.0.3

Reorganized the constants; replaced implements with static include. The javadocs look a lot better as a result.

creating a new check register

Gosh, I put on my application programmer hat and I get a very different opinion of how things should be done! I've just written a first draft of the code to create a check register. I started by writing a script to do it, but then it dawns on me that I don't want a messy JSec which reflects a series of actions to create the account--I want the JSec to contain a single JEnt which creates the account.

So I have implemented a DEnt now which creates a check register. Still I'm using RoleML, but extended to work at the application level. It seems to make the most sense to me. At the same time, it makes sense to have the low-level operations as there is still pleanty of use for them. But it is clear to me that application programmers will want to create custome DEnts which perform application-specific operations.

A Check Register?

There are a lot of things that I could work on at this point, too many in fact. But what would add the most clarity and the most utility? I think it is time to work on a better example than String2!

A check register sounds to me like a great first sample application. It is simple. It is transactional. Having a journal seems like a good thing for something like a check register. And it would allow me to knock off some of the rough edges. It should not require any special capabilities that aren't already present in COODBMS. And a check register is something most folk can relate to. Sounds idea to me.

There will two major components to a check register: (1) an API for entering transactions specific to a check register and (2) some application logic which resides in COODBMS which tracks the running balance.

Sounds like fun.

coodbms0.7.3

• All the COODBMS sample programs have been converted to using RoleML.
• RoleML now supports several iterators for navigating the database.
• Adding application logic to COODBMS is covered in a new programmer guide.

COODBMS samples have now been updated

This morning I spent some time writing an introduction on the main page and I think it came out fairly well: http://agilewiki.wiki.sourceforge.net/

The rest of the day I spent finishing up the conversion of the COODBMS samples to using DRM and JTransactions. Things are looking good.

Next I'll need to work up an example of how to extend the DRM for use with custom extensions, and this could prove interesting because of the subclassing used by the DRM. Guess I'll need to revise things a bit to make it more extensible. Shouldn't be too hard.

most samples are converted, a spot of writing

A bit of a grind today, but I've converted all but two of the COODBMS sample programs as well as flushing out the RoleML script interpreter and the DRM. The samples should be done tomorrow.

I've also done a bit of writing: http://agilewiki.wiki.sourceforge.net/ Yeah, its only a start and I find I keep covering basically the same ideas. But I need to get it right, get everything in proper perspective and improve the overall clarity.

coodbms0.7.2

• Fixed that fork bug. Just a bit of slop in the Rolon.fork method.
• TRolons now use a custom JSecs CSec which deletes the related JSecs when it is deleted. The idea here is that you may only want a limited amount of history on line. Delete last month's TRolons (which is easy to do, as the journal index orders them chronologically) and the corrisponding JSecs vanish as well.
• And hey, we've got a third of the sample code converted to using RoleML script.

new design, progress, a bug

It was a great day, though it ended on a sour note.

We've got a great new design for journals. Transaction rolons are in a transaction index now, which is under the branch index. And the transaction index is a calendar, so we don't need symbolic references to keep the transactions ordered by date.

Each transaction rolon has a csec which references the jsec under the affected rolons which corrisponds to the same transaction. And actions are evaluated, the jsec is populated to reflect the changes. The good news is that the result is both readable and informative.

Now having put the new architecture in place, samples 1-5 have been converted. Unfortunately I ran head long into an old bug--I learned now that forking does not work with parent references. So I'm calling it quits for the day. Hey, it is late enough! Hopefully I can get this bug resolved tomorrow morning and get a release out soon after that.

cowdb 3.0.2

Several of the specialized handles did not support direct links, which are needed when internal nodes are created, i.e. when the root node splits.

coodbms 0.7.1, reworing the Journal

Lots of refactoring today. CNode (which is the base class for all Rolonic Elements) now supports the dynamic creation of both persistent and transient attributes.

The RoleML script and the Document Rolon Model now both support the creation and assignment of values to Entries, as well as the methods for arranging an ordered map app.

Sample 2 has now been converted to using JTransaction and the RoleML script.

Things are looking up, but I am not at all satisfied with the Journal. You can't look at a Rolon's JUnit and get much of a clue as to what changes have been made. Here's the new plan:

• Each JRolon will have a CSec with symbolic links to all the Rolons which it updated.
• When a Rolon is updated, a JSec is created.
• For each Action (DEnt) which is evaluated, a JEnt is added to the JSec. This JEnt reflects the change that was made by that action.

The JSec will have the same headline as the JRolon and will give you some idea of the intent of the transaction, while the JEnts under the JSec will give the particulars of the actions applied to that Rolon when the JRolon was executed.

The hope here is that this will not require any extra effort when writing a RoleML script, and yet it should fully document the effect that script had on each of the Rolons which are updated by that script.

progress on Sample 2

I've started working on converting sample2 to using a RoleML script. Progress is still slow.

The resolve opcode is now working, including rolon-relative pathnames. This is used to navigate within the database.

The code for creating all the different kinds of Entities is in place, but still isn't working. Needs just a bit more effort.

I still need to work on the reordering opcodes. But this shouldn't take long. I now expect to have sample 2 done tomorrow.

cowdb3.0.1

CowDb is finally starting to stabalize, it seems. This latest release fixes only a few minor bugs found while working on COODBMS. Hopefully now the frequency of releases will also decrease.

I've been pushing hard for quite some time now, but today I took the morning off... to go to the dentist. Rupali and I took the bus all the way downtown, and that's some trip traveling from out past White Field. (White Field got its name because it was a popular residential area for Ferengi.)

lots of code, some progress

I spent the evening working on add section. One change to the API is that we'll use chained methods for headline and for exports. And for set too when I get to it. This will greatly simplify the API.

The one line in sample1 where we create a well known rolon now reads:

addWellKnownRolon("myRolon").setHeadline("...").exportPathname("context");

Tomorrow I plan on working on adding entities as well as sample2. After that I expect the pace to pick up.

I've also been careful about the javadocs for the DRM (Document Rolon Model), as that is the bulk of the API which will be used. (Unless you're making extensions, of course. But that's probably the easyest part.)

coodbms0.7

The DRM has been implemented, though it is not complete and can not be until the RoleML script interpreter is completed.

JTransaction now accepts the XML expressed by the DRM.

Still only the first sample has been converted. However, there is good news. The API for the DRM has turned out to be pretty good, as the code to generate a model Rolon is brief and readable. So this just might work!

The javadocs for the DRM are up to date. Enjoy!

Rolon-relative pathnames

When constructing a DRM (or even a RoleML document), we'll want to use pathnames to refer to other elements in the same Rolon. The best way to do this is with a Rolon-relative pathname, which requires a new notation. I'll note that absolute pathnames can not always be used as the name of the Rolon may not be known.

Rolon-relative pathnames will begin with "@". So for example, the main DSec can be referenced from anywhere in the same rolon by the pathname @/DU/main.

Of course, this required a small change to PHandle. :-(

The Document Rolon Model (DRM)

It is time for a DOM, er, the DRM. DRM will be a simple, but highly specific model of Rolons. The idea is to construct the DRM programatically, express it as XML, and then pass it in a JTransaction. It can be used then to construct the JRolons. But the XML model of a Rolon can also be passed as content to the JRolon which can then use it to create new rolons.

Now except for a bunch of convenience methods for creating DSecs, the DRM will be pretty light weight. I've already coded the base class, ElementModel, as well as the RolonModel class. So the DRM should be pretty easy to learn and use. And that will be very cool, 'cause most programming will be done using the DRM's API.

Hmm. Guess I better beef up the javadocs of the DRM.

New intro to COODBMS's Rolons

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

Got side tracked, but in a good way. I think I finally managed to put forth a good rational for Rolons. And it is time and past time that COODBMS have a reasonable intro.

Making RoleML easy to learn and easy to use

XML scripting languages can be pretty bad. In this case the use of a scripting language is justifyable, as we need to preserve the transactions now in COODBMS and that means keeping the number of classes reasonable, and XML scripting languages are especially easy to implement. But still RoleML needs to be easy to use and easy to learn or COODBMS will be just another dead project on Sourceforge. So every effort needs to be made at this time to assure success. And yes, I have a plan...

First, I've been thinking about the difference between an API and a scripting language. Methods should be fairly simple and you can use several methods to achieve a particular effect, but in an XML scripting language you want to keep the number of elements in a script to a minimum. So we want to have very powerful and configurable elements, each of which accomplishes a recognizable task. This is achievable using attributes, which can be optional. For example, an addWellKnown element can use a default Role of "rolon" and can have an optional Headline, so that with one element we can create a Rolon and give it a headline. We can also reduce the number of different types of elements in RoleML by using flags. So a make element can have a remove attribute which changes its behavior to be an add.

Second, we should have a tool for composing the XML. This can reduce the syntactic overhead, especially for users unfamiliar with XML as well as making it easy to insert variable data, like text content or base64 encoded byte arrays and serialized objects.

And thrid, good documentation is mandatory. Having a page documenting each RoleML element type seems reasonable. And the documentation should cover the composition tool as well.

Doing all this will ofcourse slow things down. But doing a good job here will more than make up for the time spent. My plan then is to take things one element at a time and complete all the tasks related to that element before proceeding with the next. That's my strategy anyway. Tactics offen dictate a slightly different course when executing a plan.

cowdb3

With this release, CowDb now fully supports XML expression and binding.

There are no additional plans for CowDb (at this time!), and there is pleanty of work to be done in COODBMS to keep me busy for a while. :-)

coodbms0.6

The new scripting language, RoleML, is working, JTransactions are now being logged and the effected Rolons have links to the transactions which updated them.

Still a lot of work left, but the first sample has been converted to the new system.

extensibility of eval

With the way eval is currently structured, it is not extensible. This can be fixed by adding an eval method to App and its subclasses and having the App classes handle opcodes specific to them. A fringe benefit here is that we get to break up eval into multiple large methods rather than having one huge method on PNode and another on CNode.

And that extensibility is key to keeping COODBMS useful for more than just the AgileWiki project.

A Very Interesting Day

Things really came together today: Some good design, implemented it and got it working. I also implemented the displayBranch opcode.

I started working on converting the COODBMS sample#1, but before I can get very far I'll need to implement a do action to execute a sequence of DSecs.

My todo list isn't very long at this point, but a few of the items will require quite a bit of work. But that's OK. It looks like we'll end up with a very fine RoleML scripting language.

On a more personal note, our return to Raipur has been delayed by a month. Rupali needs eye surgery and Bangalore is a good place to have it done.

Transaction Rolons

In that last scenario we were still missing the transactions. What we need is a master journal (a calendar) which contains a series of Rolons, each of these Rolons created by a transaction. So they are the Transaction Rolon EXecution (TREX?). Hmm, perhaps TRolons would be a better name.

Each TRolon would contain mostly just a DSec. Processing a transaction then is just a matter of creating the TRolon, creating a JEnt in the rolon which is the context of the Main DSec and then executing that DSec.

OK, so to implement this we need the following:

1. A JEnt which holds the name of the TRolon.
2. A TRolon.
3. A Master Journal. And
4. A transaction which creates the TRolon and executes it.

Hey, that's not a whole lot. And all of these things are pretty light-weight. Well we also need a Calendar App, but we can use the sorted app for now, or create a stub which simply subclasses the sorted app. Looks like fun!

Death of JOODBMS?

I've been thinking a lot about JOODBMS and Journals. My eariler thinking was that there would need to be a lot of architecture to support retrodiction. But now I am thinking that retrodiction can be achieved by a Query to one branch which then executes a transaction on another branch. Note that this would not break the threading model.

We can then simply use the existing architecture. Another advantage is that we will not have additional indexes under indexes--which is not efficient with COW technology. One final piece that we need is a Journal entry.

At a minimum, a Journal entry has a reference to a desec and the date of application. We would also keep a journal of all the journal entries, by date, applied to a branch--it is this branch-level journal which would then be used in retrodiction.

There's no reason why we can't do all this in COODBMS. Again I must quote Norm's comment about Rolonics: "Things are simpler than you would think".

Action app

Action is getting a bit more interesting. I've changed setAttribute to makeAttribute and now get and set work indirectly, so that is done. But I've also removed the context argument from the execute method--the context attribute is used instead, possibly indirectly. This opens the doors to all kinds of games, as it would easy to configure a sequencer action app to have multiple contexts--which always seems to turn out to be necessary.

more thoughts on action

I see trees of actions. If, while and for statements are easily implemented as trees.

We can also distinguish between a set attribute and a make attribute: set only changes a value while make creates one if it does not exist. Set and get attribute would also check to see if the value starts and ends with a '%', in which case the value is the name of an attribute in the owner action. This would be a great means of handling return values, where the value returned would typically be a pathname.

These simple enhancements would give us the start of a powerful scripting language... in JOODBMS.

Action App is done

A very productive afternoon--the action app class is done and integrated with the rest of the code. Still a fair-sized project remains: extending the eval method on PNode to include the API. And that really is only the beginning of an interpreter. Once the eval method is done, then we need some fancy action classes for constructing sequences and loops and branches and for navigating context.

The intent is to have one transaction class which takes an XML string and converts it to a tree of action objects and then executes them. Of course, we then need another API to compose those XML strings. So I've got my hands full. But at the same time, I'll note that the size of JOODBMS now is shrinking--it is only a bit of architecture.

But I think the API for composing those XML strings should be done as a part of JOODBMS--strictly not needed before that! Indeed, the only reason for working on this first action class is because the eval method is best done ion CowDb's PNode or on COODBMS's CNode.

cowdb2.2

There's a new TEXT role, and with full support for bi-directional XML transformations, as well as a programmer guide on the topic.

Fixed a bug in the wellKnown method--it was not using a unique name for the new node.

eval

There is still one last thing that we need before we move on to JOODBMS--eval.

Previously I was thinking that there would be numerous action classes, one for each method in the API, and that you would evaluate the action. I realize now that I had it backwards--there will be only a few action classes (for different content) and the persistent object evaluates the action.

Actually, we'll likely have it both ways. There will be an execute method on the action which then calls eval on a selected pobject.

Transactions then can carry an XML document which XmlBinder converts to a tree of actions which get executed. The intent here being to reduce the number of subclasses of transaction, for in JOODBMS transactions are persistent objects and that means the class loader must be able to load the class of every transaction ever executed.

Some actions will also need to carry content, like Bytes, Serializable and text.

CowDb release 2.1

There are two new helper classes:

Xpress uses the IDisplay interface to create XML fragments. No other changes were needed to the code base to implement this, though this means that Serializable and Bytes are not properly handled. (That will come later.)

XmpBinder parses XML documents and creates a graph of nodes from the result. Not everything is supported [yet]. In particular string atts with new lines will not work. Again, this effort needs to be revisited. Implementing this required some changes to the code base to process the attributes.

The point here is to do the necessary minimum to lay the foundation for JOODBMS. Some real effort will be needed [later] to turn these classes into something useful. On the plus side, both these new classes should be an easy read for folk with an interest in such things.

Oh yes, the sample code for defining a new app has been updated with a method for processing XML attributes.

CowDb 2, COODBMS 0.5

The simplified API is in place. In the process of doing the release, I found 4 bugs relating to the b-tree logic. Two I fixed, but the other two were in the iterator's remove method which I disabled. On reflection, I now see how I can now implement that remove iterator.

Overall, not the nicest of days. But it is always good to find bugs.

------------------

OK, the remove method been fixed now, tested and checked in. It'll be included in the next release. I'll note that the workarounds were not the fastest approach, so it is good to go back to using the iterator.remove method.

CowDb 2 API, RoleML

We need to first identify which roles will have a small footprint and which may not, which requires a bit more metadata to be supplied by the CowdbFactory's plugin method. Once that is done, we can make the add and make methods a tad smarter.

Add and make must also look at the map node which will hold the new node. If the map node support embedding other nodes and the role of the new node is identified as small, then we will embed the new node in the map node. Otherwise the new node will be given its own space on disk and a direct reference will be added to the map node.

The goal here is two fold. First, we put are taking the decision to embed or not to embed a node out of the hands of the developer, who has enough other things to deal with and would rather not be concerned with this issue. Instead, the designer of a map role makes the determination about having the role support embeded nodes or not and ask the designer of all roles to determine if a new role is small or not. Using the CowDb 2 API then becomes much easier to learn and to use, as well as becoming much cleaner.

The second goal is to minimize the XML representation of a graph of nodes. The role is used as the element name and we will need only a few attributes:

• The name of the node.
• The well known name of the node.
• The immutable name flag.
• The headline (for COODBMS).

Direct references need not be represented in XML. However, in the case of symbolic references we will need an XML element. Again, the role becomes the element name and we will need a few attributes:

• The name of the handle.
• The immutable name flag.
• The symbolic reference.

We also need to handle attribute values and custom roles. This will require additional API on the App class for XML binding and XML expression. So even though we only need XML transformations for JOODBMS, this has to be driven all the way down to CowDb for a clean implementation.

RoleML seems to be a good name for this markup language. Note that it does not have a fixed schema, as new roles can always be defined which carry their own unique content. The alternative would be to just use node and handle as the element names and carry the role as an attribute. But that breaks the original spirit of extensibility and makes for really ugly xml, especially as the role maps so very nicely to the XML element name.

cowdb1.1.1 & coodbms0.4 released

CowDb1.1.1 contains a minor bug fix. COODBMS0.4 includes headlines, keyword access and dynamic creation.

Two things are next on the list: More API cleanup for CowDb and streaming for COODBMS. Sounds like fun!

timing and order

I've been thinking about keywords and headline searches and have concluded that this is not a good time for headline searches. JOODBMS is close at hand and involves some major architecture. So it will be better to let the dust settle before working on other things which also involve architecture.

Now yes, the same argument can be applied to keywords, but in this case I'm going the other way. This is a small project (and nearly complete) and a valuable one, as it involves a typical CSec. And it can be easily redone if necessary.

AgileWiki3 supported a wide variety of CSecs from which it gained considerable power. COODBMS is still a pale foreshaddowing of things to come.

good progress on COODBMS, searching

I've completed headlines and nearly completed keywords. But now I'm thinking about searches.

The headlines add a nice descriptive classifier to all Rolonic elements, but it would be great to search on those headlines. I'm thinking it wouldn't be too hard to build up some indexes and respond to a search request with the best N matches. Something worth thinking about anyway.

Once I finish keywords, I will likely go back to CowDb and simplify the API. Again. Then I can work on streaming, which lays some necessary groundwork for JOODBMS. But working on keywords has been fun. Turns out I overlooked the most common form of handle used in Classifier Sections--Symbolic Handles--which I've now added to COODBMS. (I need symbolic handles to implement the keywords csec.)

light-weight Rolons

Units, Children CSecs and Parents CSecs are now all created as needed. I've checked in the updated output for the samples and everything is ever so much easier to understand now, as well as reducing the footprint on disk and speeding rolon creation. All 'round goodness.

yet another change for CowDb?

Right now the CowDb API is complicated by the fact that some nodes are embeded in others (makes for fast retreival) while others are placed in their own physical block. And when we introduce XML transforms, we need to preserve that information. Besides being a pain, it will also be added clutter in the XML document. Not good.

Now the amount of metadata we are carrying on a role has grown lately, but perhaps we need to add one more flag to carry this information. then we can drop the addReference and makeReference methods. This will will make the sample code much easier to understand, and that is important too.

So I'll add another planned feature to CowDb, just when I thought we were done with it. But for the moment my focus will be on COODBMS.

cowdb1.1

CowDb is perhaps (hopefully) complete now. Release 1.1 was all about finishing touches.

• Handle code is now easier to read.
• Footprint on disk has been reduced.
• Symbolic references are faster to resolve, thanks to the use of direct pathnames.
• And a bug fix in multi-node b-trees has been made. (I believe this bug was introduced in 1.0.)

So if all goes well, I can now focus on COODBMS and JOODBMS. I am especially excited about dynamically creating the various elements of a Rolon, as this will reduce the footprint of the less-developed rolons as well as adding making the sample output easier to read.

cowdb1.1 is nearly ready

Except for optimizing the footprint of handle and some final testing, cowdb1.1 is ready to go. Expect a release tomorrow.

headlines, keywords

One thing I've left out of COODBMS is headlines. A headline is just an optional title that can be attached to any rolonic element. Easy enough to add.

It would also be great to add a classifier, like keywords, to provid an alternate means of access--pathname not always being the most appropriate way to find something. We should have one well known rolon, keywords, which has a the various keywords as children under it. A rolon which "has" a keyword would hold symbolic references to the keyword rolon in a keywords CSec. Keyword queries then would examine the backlinks on the keyword rolon.

Much as I want to move on to JOODBMS, it seems to me that it would be self-defeating not to give COODBMS some additional utility. This also gives a bit of the flavor of Rolonics, as headlines and keywords would be available to any application implemented over COODBMS.

Beta release of COODBMS

Finished updating the docs and made the release. COODBM 0.3 is out.

Now it's back to CowDb to work on the 1.1 release. Then a bit more work on COODBMS before (finally!) starting JOODBMS.

JOODBMS is going to be dealing with high-level architecture to provide a flexible structure for managing Journals. I suspect that there will be some heavy lifting involved and I want to take care that COODBMS will be able to meet all the requirements of JOODBMS--which is why streaming will be added to COODBMS.