its woikin

COODBMS samples are all updated and working, so it is on to the docs and perhaps a release tomorrow.

Found 4 bugs in the new COODBMS code and NONE in the CowDb code while working on these samples.

I've also disabled the immutableName flag display in CowDb for better lookin' output.

COODBMS progress, streaming

Progress on COODBMS has been rapid. I've just now completed the rewrite of the code. Now I need to update the samples and the docs.

The next step for COODBMS will be streaming:

• XML => Rolon,
• Rolon => XML and
• Rolon => Rolon.

Streaming is a powerful mechanism. I've done a lot of work with streaming in the past, https://sourceforge.net/projects/jxquick but this time it will be much simpler/faster as I need only support rolonic structures. We'll use streaming to copy DSec, Rolons, etc. Streaming also lends itself to generating displays, but I'll not take it that far right now.

I also suspect that before working on streaming (which is needed for JOODBMS), I'm going to return to CowDb and work on the 1.1 release.

a good night

Just had a great talk with Sanjay, my brother-in-law in Raipur. Looks like we are being welcomed with open arms. So it is looking like we are go for moving to Raipur the end of this month. The plan is to spend a year living with the Pandeys and working on nothing but Agile Wiki. A marvelous opportunity, and one that would be quite unlikely in the US. India has its strengths, and one of them is that you don't need to be a wage slave your whole life.

I've now stripped calendar from both CowDb and COODBMS. This is an important App and I want to give it the attention it deserves, in the proper time.

I've also completed the conversion of COODBMS to the new API. I love it! Next will be to implement Entries, which was simply inconcievable with the old API. (Oh, it would be doable. But there would be too much code and it would be difficult to add new attributes--which would be a very bad thing!)

I don't expect the implementation of Entries will take much time. Just one subclass of CNode and a bunch of meta data added to CoodbmsFactory. Should be a breeze!

I also don't expect the conversion of the COODBMS samples to take much time. I may even be lucky in debugging COODBMS as it was working before and builds on a working CowDb and hay, there is a lot less code now.

The effort, I expect, will be in updating the docs. And that's a good thing. :-)

plan for 1.1, progress on COODBMS

Just updated the CowDb with the feature plan for release 1.1. http://agilewiki.wiki.sourceforge.net/CowDb

I am also working on updating COODBMS to use the new CowDb API. Interesting how important the addition of the owner method in cowdb1.0.3 turned out to be in COODBMS.

Now I had said that COODBMS would be a thin layer over CowDb, but then I started cranking out a lot of code. With the new API, it is finally becoming that thin layer of my original vision. I do not believe that COODBMS will have much value except as an example illustrating the power of CowDb. (And as a necessary step towards JOODBMS which should be quite interesting.) I may even finish roughing out the code for COODBMS tomorrow and complete the conversion of the samples this weekend. Everything has just gotten a whole lot easier.

I've also decided not to implement calendar until JOODBMS. It is just not needed, as JUnit is really just a place holder for now.

cowdb1.0.3

I was not planning on doing a release today, I'd rather spend the time on COODBMS right now. But then I found this bug. Turns out the internal nodes were not as transparent as they should have been. So this is an important bug fix, especially if you are evaluating CowDb for a reasonably sized application.

Now there are some changes planned for CowDb which will break backward compatibility. But right now it is important that CowDb be good and solid. I'll release those planned enhancements as a group--in the 1.1 release.

started on COODBMS

Started work on updating the COODBMS. It is going well and I must say, the new CowDb API seems to be meeting my every need, and quite nicely too. But I think it will take a week or so to complete.

Done with the docs for CowDb

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

I've just finished reviewing the programming guides, updating the terminology and method calls. Should at least be somewhat helpful in getting started. Suggestions are welcome!

The biggest change of course was to the page on defining new persistent objects: http://agilewiki.wiki.sourceforge.net/DefiningNewPersistentObjects

I've also proposed a number of enhancements to CowDb, but I think those will wait for now: http://sourceforge.net/tracker/?group_id=106672&atid=645208

Right now, the most pressing item is the revival of COODBMS. It needs to be converted to the new CowDb API and serves as an advanced example of what can be done using CowDb.

A good start on the cowdb1.0 docs

Made a good start on the docs today for cowdb1.0. Found a bug (spurious links and backlinks tables), fixed it and released cowdb1.0.2. And then anounced it on fresh meat. So it has been a busy day.

Rupali is back from visiting her family in Raipur. Which is good, 'cause I've been working way too hard. We plan to move to Raipur come the end of Feburary so we can save money, as I am working full time right now on agile wiki. (Bangalore being a bit more expensive than Raipur. We'll be living with her family, which doesn't exactly thrill Rupali.) The question is, can I find fame and fortune working on open source? Not likely, but then anything is possible.

Hopefully I can wrap up the docs for cowdb tomorrow and then move back to COODBMS. This is exciting, as I'll be using the new CowDb and that is something I am very much looking forward to.

release of cowdb1.0.1? !

I've gone ahead and released 1.0.1, and still I have not updated the docs for 1.0.0! Well, there is a good reason for this.

First, I found a serious bug in the b-tree split logic. So I had to get that fix out the door. A good excuse anyway.

Second, in 1.0.1 I've finally split PHandle into 6 classes. It was way too confusing as a parameterized class. But while I was at it, I reworked CowdbFactory a bit and now you can add your own custom handle classes, should you be so bold.

Finally, when I write the docs I want to talk about how CowDb has 3 things, Nodes, Handles and Apps, the user defines roles as a combination of these and all 3 can be extended. So I really wanted to get 1.0.1 released before starting the docs.

cowdb1.0.0 and beyond

Well it all works, and it is released.

Docs will follow, but all the updated test code and samples are included in the download, along with javadocs of course. I also want to tweek the internal architecture just a tad before writing too much documentation. But you can expect [much!] smaller changes going forward.

Now aside from finishing calendar, there is one other small feature I want to add--XML input. This is something I plan to use (for transactions) in JOODBMS.

Oh yes, there is one other very nice thing about cowdb1.0.0. The Display class has matured a bit and the output from the samples is much easier to read. (Again, its all in the download.)

As for immediate plans, I do need to get back to COODBMS. Likely after doing the new CowDb docs.

finished CowDb core, roles

Finished implementing the new API and internal architecture of CowDb. Updating the samples, tests and docs (and likely, more debugging) is what remains. Release should be in 1 or 2 days.

There are now several subclasses of PNode: RootNode, IndexNode and InternalNode. Each of these classes is associated with a role which requires specialialized behavior on the part of the node. There are now 11 subclasses of App for associating application logic (capabilities) with a node. Adding to that, PHandle is a paramaterized class whose behavior is governed by the handle type--and there are 5 types of handles. Overall, that makes for a pretty rich and flexible architeture. And you can easily extend it with new Node and App subclasses.

In this new version of CowDb I'm introducing the idea of a role. Within a graph of nodes there are various roles to be performed. And Nodes are created/configured by the CowDb factory based on the role. And there are 23 different roles defined.

The role determines the class of the node, the class of the associated App class, the handle type and the Internal Node role. And all of this can now be configured using the CowdbFactory.plugin method. Creating a new node is a simple matter of calling PNode add(String role, String name) on an existing node--this inserts the new node in the same physical block as the container node. But if you want the new node to have it's own physical block, then you call PNode addReference(String role, String name) instead. (The rest of the new API is just as easy to use, and a considerable improvement over the old API.)

The new CowDb then is very very extensible, and it is quite easy to extend--once I update those docs!

an interesting and productive day

SVN on sourceforge for projects beginning with the letters a, f, l, m, t, y, and z is currently unavailable--hardware problems.

All but PRoot & Allocate have been converted to PNode/App pairs now. I've also gotten some of the samples working again. Once PRoot and Allocate have been converted I can chop out a fair amount of code and clean things up a bit more. Pleanty of work left to do, but the completion of this conversion to the new API still looks feasible for this weekend.

Rewrote b-tree today, new nominclature

Rewrote b-tree as an app object, but about half the time was spent or factoring common code out of what used to be called list. So both classes are now much lighter than before.

I'm also renaming things. CowDb will support 3 kinds of persistent maps:

1. ORDERED --this was the old list. It allows you to arrange its keys.
2. SORTED--used to be large table. This is an implementation of the b-tree algo.
3. HASH--used to be large hash. Still to be implemented, likely this weekend.

Now I've also extended the metadata in factory a tad so you can specify the internal node type to be used by SORTED and HASH. This eliminated the need for wellknown, links and backlinks classes.

Cheers!

transitions can get ugly

The new API is largely in place, with scalars and List converted. Spent the day on the test suite, the cowdb samples and flushing out the API with a number of convenience methods. But I still need to convert btrees and hash tables.

All the code is in working order, but with two distinct API. It is an ugly duckling right now, but looks like it will soon be a beautiful swan. I expect the final code base to be smaller and simpler than what I started with, as well as more powerful, more extensible and easier to learn and use.

I've still got some heaving lifting ahead of me to complete this conversion, and then I need to go through the code and cut out the dead wood. There is a lovely, light-weight CowDb trying very hard to shed the fat old API.

Tired, but excited. --b

a truely wonderful disaster

Spent the whole day working on the new ListApp. I just ran two test cases and they both worked. But the API is disasterous--very difficult to use. Fortunately that is easily fixed with a few tweeks. So I am very happy with this disaster. Which is a good thing, because I've got a lot of work ahead of me.

In one sense this change is a tremendous simplification. I expect to be able to chop a lot of code out of COODBMS. There will only be two classes used to create structures in CowDb: Node and PHandle. But at the same time, there can be any number of much simpler helper classes creating Node companion objects to add a wide range of functionality to those nodes. So it is the best of both worlds, simple but rich.

status, peer/app from a Rolonic perspective

First I want to report that I have not yet started converting PList. But I have worked out a strategy for the conversion. Second I want to report that all the code is in working order.

Now Peer/App pairs are a bit like AWT--you don't ever get one without the other. But in this case it is the factory which decides (using some tables) which class of App goes with a given type of Peer. One difference to note here is that Peer is the object which the programmer creates, while in AWT it is the reverse.

Peer/App is also a bit like COM aggrigation. The Peer holds the App object and exposes the App's interface.

But a better (i.e. more Rolonic) way to think about Peer/App is that Peer handles partness (i.e. Peer deals with the framework) while App largely handles logic and state. App then is almost a POJO, except that it is aware of its environment (via calls to Peer) and is responsible for its own serialization. As usual, there is no history/Journal--that will not be implemented until we reach JOODBMS.

IAttributeApp

Well, the first step in the conversion to Peer and App classes is done and working. We now have 6 classes which extend the App class and which implement the IAttributeApp interface. This went a lot easier than I had figured.

The next step is to convert PList into an application object which works with a Peer object. And that may not be quite so straight forward. After that I'll worry about large hash, large table, index and the rest.

a more general solution

The idea of having a wrapper object worked great for int, long, String, boolean, byte array and serializable objects. This is because all of these have only Object get() and void set(Object value) methods. But using a wrapper is not generalizable.

Basically we want to have two objects, an application object and a peer object, where the application object is only required to implement a simple interface and the peer can be subclassed (e.g. in COODBMS). That is a solution which will work for every case, but it is a big change. And with all the code we've got, it would be best if that change could be implemented piecemeal.

So we can begin by supporting the peer object--which looks like a wrapper to the internal code--with additional support in PContainer for the App getApp(key) method. It will be a bit of work, but should be worth it.

This approach also solves another problem--the interfaces exposed in the API is far too complex. All that complexity now moves into the peer and the only method left exposed in the API is the Peer getPeer() method. So we get to kill two birds with one stone.

an extensibility issue, wrappers are the solution

I've not written the section entry class in COODBMS yet, and for good reason--I would need to duplicate a lot of code for each PObject to make it aware of the Rolon it is a part of. As it is, for each container used as a section (lists, large tables and now calendars) I've already had to duplicate a good chunk of code for each Section as well as for JUnit. There is a problem here.

The problem stems from Java's lack of inheritance. The answer it to employ wrappers. Doing this will increase CowDb's extensibility considerably. Implementing this can be done entirely transparently using the type code. We just create another map for mapping a wrapper's type to the base object that it wraps. Also, with wrappers it should be a lot easier to implement a range of base objects.

moving calendar to cowd, CowDbML

With calendar now little more than a b-tree, I am thinking that it should be moved down into CowDb--it is entirely usable at that level. COODBMS then stays tightly forcused on organizational structures specific to Rolons.

Also, for JOODBMS we need a notation which allows us to add transactional Rolons to the database. For this a simple XML markup language, CowDbML, would do the trick. This naturally extends into a logical block (like PByte or PSerializable). Note that since we already have a factory driven by type strings, the type string simply becomes the element name in the markup language. But we will need to change the type constants to be something a bit more readable.

COODBMS almost done? JOODBMS

The only thing remaining to be done in COODBMS is to add some methods to calendar--right now is simply extends PLargeTable. And to work up some samples, of course.

Now I've been giving some thought to the architecture of JOODBMS. There will actually be several layers of index.

At the highest level we have the system index which holds the various root branch indexes.

The second level has the root branch indexes. Each one is a virtual database, created from scratch or as a copy of another root branch index. The root branch index holds all of the transactions (which are rolons) and a master rolon which manages things. The JUnit of the master Rolon (a calendar) holds symbolic links to all of the transactions. The LUnit of the master Rolon holds symbolic links to the indexes at the third level.

The third level has indexes which hold the application Rolons. The JUnits of these rolons hold symbolic links to the transactions on the second level which updated them.

With the Transactions at the second level and the application Rolons at the third level allows us to create new copies of third-level indexes and execute selected transactions against them. So we might have a snapshot of the application at the start of the month and then re-run the transactions for the month against different copies of that snapshot. Each run might be with a different code base, or we might add/delete/update the transactions themselves before re-running them. Then you can compare the results.

As for space management, we can simply delete the transactions for previous months by using the master Rolon's range iterator--this is the power we get from building on top of COODBMS.

Could prove quite interesting.

coodbms0.2, calendar

Release coodbms0.2 is out with full support for organizing Rolons (trees of persistent objects) into non-cyclic graphs (bush structures). Freeing an object maintains the integrety of these structures. Fast deep copies (using Copy-On-Write technology) for Rolons and entire bush structures is supported as well. (But I still need to update the COODBMS docs.)

Now my thoughts are turning to the next (and final?) aspect of COODBMS--Calendar Sections. It occurs to me that calendars are best implemented as a b-tree (large table), so the next step is to extend COODBMS to support b-tree sections. (Currently all Rolonic elements subclass PList.)

COODBMS basics are working, finally

It is after midnight here, but I've finally got the basic structures of COODBMS working. (I'll work on the releases for CowDb and COODBMS tomorrow.) I've been very close for some time, but now it is both working and clean. And I am quite happy with the result.

This leaves only calendar sections (and a tad bit more documentaton) before moving on to JOODBMS. So expect some posts on JOODBMS. Hopefully it will kick off a lot easier than did COODBMS.

feeling good about release cowdb0.12

The cowdb0.12 release has had a major cleanup. The code has now been refactored to the point where calling free on an object gracefully removes it from any arbitrary object graph. A container interface has been added. And bugs have been found/fixed in handle and the various container iterators. A new method, all, has also been introduced on the Display class which lists all the objects in the well known table. Overall I'd say that cowdb is now a lot more programmer friendly.

The next step now will be to do a similar cleanup on COODBMS.

Norm's new blog

http://rolonics.blogspot.com/

Initial post is only a teaser. And I don't expect this blog will really take off for a few months.

cowdb0.11.3

Release cowdb0.11.3 has had the PHandle clear method refactored. A small change, but it will make a huge difference to COODBMS. PRolons will now be aware of when a well known name is removed, when a reference from the links table is removed and when a reference from a child or parent rolon is removed, and can take appropriate actions.

The removal of a reference from a child Rolon or from the links table will initially be noops. But when we add namespaces (and later, inferencing) these will become significant events. As it is, COODBMS need only address the removal of a reference from a parent CSec or from the well known table--and gracefully delete itself when appropriate.

Things should proceed a bit smoother now.

time to revisit CowDb

In COODBMS I've really pushed the extensibility of CowDb and have found some issues which require very minor changes to CowDb.

First, there is a bit too much coupling between the type code of the container of a handle and how the handle processes that container's symbolic links. So it is time to introduce symbolic link types. This will be done with a method on LogicalContext which in turn uses a simple map in the factory. (And additional constants introduced in the constants interface.) Symbolic link types can then easily be changed by subclassing the factory.

Second, the logic for handling well known needs to be moved out of the well known table and the handle and located in logical block, where it can be easily subclassed.

And third, logic for removing a symbolic link needs to be moved to PObject where again it can be easily subclassed.

These changes are minor and should have virtually no impact on how CowDb works. Only they add to CowDb's extensibility and reduce that great evil, coupling.

Things are going very well

Progress on the COODBMS is going well. I believe the result is going to be very simple, very powerful and, as we implement the remaining aspects of basic Rolonic theory, universally applicable. I really can't wait to see how the Retrodictive Database developes--it should be very interesting as this is the least developed area of current programming practice. And it is a whole lot more than just retrodiction.

On a personal note, Rupali and I will likely move back to Raipur (CG, India) to save some money as I am dedicating myself fully to this project. A bit of a gamble, but I have every expectation that the effort will be worthwhile.

My earnest hope is that I can open the door to a whole new way of thinking about programming and a new understanding of what knowledge is. And that others will follow.

CowDb has some features which are, I believe, somewhat interesting. I suspect that folk will be wondering a bit about why I bothered with COODBMS at all. And I don't doubt that the Retrospective Database looks like something with only obscure applications. But it is all part of a larger whole, and as we move forward I know that everything will come together nicely.

Can't wait! --Bill

coodbms0.1 Released!

Finally, an initial release of COODBMS!

Docs have been updated as well: http://agilewiki.wiki.sourceforge.net/COODBMS

Tomorrow I'll start on the Parents and Children CSecs. :-)

cowdb0.11 is out

While extending lists in cowdb to support PObjects, I found a bug when forking a list. This has been fixed.

PXTable has now been replaced by PList. Less is more, but I do hate breaking backward compatibility. But all the old tests for xtable now use list and so the confidence level is higher. And it might be just a little bit less confusing--we now have only 1 hash, 1 table and 1 list.

I'm exhausted now and need a break. Later today I'll update the documentation for COODBMS and perhaps tomorrow I can start implementing the parents and children classifier sections. :-)

Need to change lists, children and parents

A Section in a Rolon can contain Section Entries. And a Section Entry can be a PObject, like PString. But a Section is a list. Whoops! Lists need to be able to hold PObjects. Gotta fix that!

Meanwhile I've been thinking about the implementation of the Classifier Sections (CSec) Children and Parents. It is really pretty simple--these are just lists of handles which contain the unique names of the rolons. (This is just like the way the well known table works.) Forking and changeKey will require a bit of work, but that should not be too difficult.

I've also completed roughing out the implementation of Rolons, Units and Sections and even have a first working sample. I was planning on updating the docs now, but fixing list is a tad bit more important.

COODBMS, Phase II

So far, I've described how the content of a Rolon is organized. What has not been addressed is how Rolons are organized. Simply put, they are organized into a bush structure, which is like a family tree--children can have more than one parent, but cyclic structures are not allowed.

A bush structure gives us more flexibility than a pure tree, but at the same time it still works with reference counting. We'll want to add an additional rule however: a rolon should be freed when it is not well known and when it no longer has any parents.

Now here is where we start to employ Classifier Sections. Indeed, we will use two: the Children Classifier Section which has symbolic links to the child Rolons and the Parents Classifier Section which will have symbolic links to the parent Rolons. There is also another restriction which will make implementation easier: The parent and a child Rolons must both be under the same Index.

Now phase II may involve some subclassing, PHandle in particular--both to handle the new reference counting rule and to prevent the generation of links and backlinks. (In this the parent/child relationship will work much the way well known name does, but in both directions.) But it shouldn't be too difficult.

I believe having a means of organizing Rolons is an important part of COODBMS, as otherwise it is simply not complete.

Things seem to be back on track

I've just released cowdb0.10.3--Lists now support the changeKey operation and names are no longer immutable by default. These changes will be quite important going forward.

CowDb2 is now gone from the web pages. COODBMS is back, but in a simplified form: http://agilewiki.wiki.sourceforge.net/COODBMS

At this point it looks like the implementation of COODBMS will go pretty quickly. And I've already started thinking about the retrodictive database--that will be real fun!

Back to the Future

It would be a whole lot better if we were able to implement Rolons as a thin layer over CowDb, as this better assures support for CowDb (my time being limited, I would otherwise be inclined to abandon support).

We would need to implement a getMyRolon method on the PSection class and any class which needs this information. This does not sound too good in general, but will be quite workable in practice. Section Entries which need access to the Rolon that they are a part of can now only be in a Section, though they can be referenced by other objects of course And that is a very reasonable restriction.

So it is looking like we're going back to COODBMS and dropping CowDb2 completely. Hopfully this third attempt will be the charm. :-)

Gowing forward

So what to do about the CowDb2 design flaw? After sleeping on it, I've reached some conclusions:

• Support for changeKey in PList needs to be back ported to CowDb.
• I need to start CowDb2 over again.
• The layered approach I was taking in the eariler COODBMS still will not work.
• The clarity I gained from the work done yesterday was worth the effort. (Though it still does not feel like it!)
• Norm's observation still applies: "Rolonics is simpler than you think."

Design flaw?

I spent the day working on CowDb2 and made a lot of progress, but I may have a design flaw.

The basic question is, are Rolons Indexes? Or are they just First Class Objects? My assumption today was that they were Indexes and that Sections and Section Entries were First Class Objects under the Rolon/Index. This has two problems:

1. When you copy a section, you no longer have a pure tree. That's wrong.
2. Determining the pathname of a subsection or entry becomes very difficult.

Major woops. Now do I undo many of the changes I made today, or do I start over? :-(

Time to start something new--CowDb2

I've been thinking this morning that there are some major changes that I need to make, as I'm now thinking about cowdb a bit differently. So it is best to bring CowDb to a close and start work on a proto-rolonic database--which would begin life as CowDb but with a somewhat different terminology. For want of a better name, lets call it CowDb2.

In CowDb2 we will add sections to the object context. Sections are organized as trees under indexes and replace the well known table. Also, each transaction will be targeted to a specific index. We should also rename index, as it becomes our proto-rolon. Perhaps PRolon.

So it is time then to wrap cowdb up and release it.

Ledger Sections

There is a rolonic concept called sections. Each aspect of a rolon has sections and sections can also have sections. Basically I want to make well known into a rolonic ledger section.

Now sections are interesting because their parts can be ordered manually, so sections are lists. but each subsection is named. Now the current implementation of list supports manual ordering, but assigns an ascension number to each part. But it would be easy enough to allow the user to provide a key in place of the ascension number. Then we can change the well known table to be a list and then support a tree of such lists. This then gives us the start of ledger sections.

bifurcation

I think I've been trying to scratch two itches at the same time. Folders will be for organizing rolons, but I think it is too soon for them. What I really want right now is to turn the well known table into a tree structure. As a simple tree, pathnames can be fully implemented. And it can help with organizing calendar elements--they would simply be specialized nodes in the well known tree.

So I've been thinking about implementing bushes when I really just want a tree. It has been quite a distraction.

The good news is that I finally finshed up lists--they'll be included in the next release.

COODBMS is Dead

With the addition of reference counting in CowDb, the thunder has been taken out of COODBMS. Adding insult to injury, a lot of the cleanup of CowDb has greatly reduced the changes necessary to implement COODBMS. The last straw was CowDb's support for dynamically loaded classes--there is no longer any justification for COODBMS as a distinct layer.

PLists, PFolders and PCalendar will now be added to CowDb. COODBMS is dead--long live CowDb. :-)

CowDb has too many kinds of tables

There is a needless excess of table and hash table types in C0wDb. This makes it harder to learn, and that's a no no. Really, we need only two:

1. Large tables (b-trees), which can hold PObjects as well as references to logical blocks, and
2. Large extensible hash tables.

This will bring some much needed clarity to CowDb. And that is very important. But right now, I'm working on a major hole in the reference counting logic. :-(

Folders

Folder is derived from index. The Root Branch Index is not a Folder, it remains an index.

The intent here is to create a bush structure, where a folder may be a child of one or more other folders. This is achieved through symbolic links. This is distinct from being under another folder or index: if B is under A and A is copied, then B is also copied. And if A is deleted, then B is also deleted. Let us say that folders B, C and D are under index A, B and C are well known (to A) and that D is a child of B and C. Now if B and C are both deleted, then so is D.

Now what we want to achieve here is an expansion of the idea of the well known table into a bush structure. A lot of what we need to achieve this is already included in CowDb. What remains to be resolved is how pathname will work.

We can keep getPathname as it is now. But then the pathname will contain unique names, as Folders will need to have unique (generated) names. This is probably good enough for us in the links and backlinks tables and helps us avoid level confusion. We then need to introduce a second level to pathname which uses the parent/child relationship of folders. The pathname resolution logic on Folder can of course be augmented to use this new relationship between folders, but getPathname should not be so enhanced.

The overall purpose of COODBMS is to provide means of organizing objects by way of lists, folders and calendar. Objects will be accessible by multiple means, as more than one (and more than one kind of) structure can hold a reference to an object.

Is it soup yet?

Release cowdb0.10 is out. The big feature is reference counting. Hopefully now I can focus on COODBMS.

I will admidt, I've cheated a bit. I've been thinking a lot about COODBMS and that's why there were a lot of changes made lately to CowDb.

I expect COODBMS will be quite different from CowDb. The code should be a lot simpler, and overall it should be much less interesting. On the flip side, COODBMS should proove to be quite useful.

reference counting

I've been thinking long and hard about reference counting and methinks it is time to add it to cowdb. Here's the algo: when removing a symbolic link to an object, the object should be deleted iff

1. the object has an immutable name (typically a unique name),
2. the object is not well known and
3. the object no longer has any backlinks.

OK, it is not full garbage collection. Circular structures will still need to be handled by the application programmer. But still it should be quite helpful and will be particularly useful when we get to COODBMS Folders.

I also expect this to be the final major feature to be added to CowDb. (Hmm. I think I said that before. Hopefully this time it will be true and I can turn my full attention then to implementing COODBMS.)

Enhanced docs

This morning I reviewed the programming guides and updated them. Then I added a few tables to the CowDb page, a table for persistent objects, logical blocks and containers, which I expect will be quite helpful: http://agilewiki.wiki.sourceforge.net/CowDb

cowdb0.9.1

OK, I've refactored the whole API for CowDB. It is smaller and more extensible. And a lot cleaner. The release has been posted on Sourceforge, only I need to update the online docs. :-(

Yuck!

I'm half-way through refactoring the convenience methods and have realized that (1) it makes for pretty unreadable code (i.e. not convenient) and (2) there is just way too much code (static methods at that!).

Better to just have some generic code on PHandle and PHTable and have the application programmer pass the type in an added argument. But I think that is a project best left for tomorrow. For one thing, this will greatly reduce the amount of code needed to define new types of persistent objects, and that's a real plus!

problems with convenience methods

Currently in CowDb there are many convenience methods on PersistenHandle and HandleTable. Aside from cluttering up these classes, Java's lack of mixins or multiple inheritence make it very difficult to add to the convenience methods in subsequent layers (COODBMS being a case in point, but this applies to applications as well). The answer is to change these methods to static and move them to the classes they apply to. So rather than having a getList(String key) method on HandleTable, we'll have PList.get(IHandleTable handleTable, String key) method.

Ugh! This is not the nicest oo practice, but at least it is extensible. It also means I've got a big refactoring job to do in CowDb, and right after announcing 0.9 as a beta release. Well, there is still a silver lining here--this will not require any changes in the data in the database, so we will still have backward compatibility with the db file.

a discussion on rolonics

The discussion form has been inactive since like forever, but Peter and I have been having a discussion there on the nature of Rolonics which you might enjoy: https://sourceforge.net/forum/forum.php?forum_id=367038

cowdb--done but not finished; CowDBMS

Release cowdb0.8.11 should come out today. It includes the last major feature--integration of deep copies, symbolic links and the changeKey operation. Now a symbolic link still does not require a referent--you can have a dangling symbolic link. But if a link references an object and the pathname of the object changes, then the symbolic link is updated to refer to the object with its new pathname. The trick here of course was to keep it fast, and it is. Deep copies and key changes take order n time, where n is the number of symbolic links that are directly impacted.

CowDb then is done. But it is rough. It needs polishing and more testing. I've also decided that the next product in this series is not the retrodictive database, but rather the Cow DBMS. In CowDBMS we will introduce some organizational structures, folders and calendars, and move a bit further away from simple tree structures.

level confusion

I've been working on backlinks and have realized that pathnames need to be unambiguous. This is very much in contrast to the semantic qualification of AgileWiki3, where backlinks were resoved using an applicability mechanism.

So it looks like I need to go back and cleanup pathname resolution. And to support .. notation as well. But at least now I've got a clearer idea of how to handle backlinks in cowdb.

Once backlinks have been implemented then finally cowdb will be in beta. Here I have a very precise concept of beta--backword compatibility of new releases with the data created by previous releases. But to achieve it, the persistent data structures need to be quite stable.

Meanwhile there has been some good progress made. The Control class, as an example, now carries a reference to the root branch index--which makes it much easier to resolve an absolute pathname.