more thoughts on Journal
First, the design has gotten to be a bit much, while still being inadequate. In AgileWiki3 we had the ability to navigate links in past time and we should again be able to do that.
One simplifier is the mandate: keep Rolons small. As soon as you start trying to do do much in a Rolon, you start down the same path of oo and end up needing a lot of custom code. Building networks of Rolons yields a far more accessible structure. Rolons are simple trees and you should not push them too hard. (Case in point--I'm creating a structure to describe commands and could easily define new attributes to identify queries and scriptable. But by using multiple parents I can achieve the same thing without needing new attributes. And then I also have fast access to all queries, etc.)
Now if we assume rolons are small (without putting any particular limit on it--we still allow for very scalable sections), then we do not need to be able to view all the changes specific to a section--we just view the Rolon's journal for all the changes for the journal. This greatly simplifies the proposed design.
Snapshots created when a transaction is processed need to be named what-when, where what is the name of the updated rolon and when is the timestamp of the change. Now we can include the classifier in the snapshot, so long as the same snapshot is added to all the links, extending the rolon name being linked to. Link resolution then is just a tad more complicated and is very reminiscent of AgileWiki3--resolution will be to any snapshot of the same time or earlier.
Oh, and there is one other constraint. When purging, we must always keep the oldest snapshot of those being purged. Otherwise link resolution will fail.
This will not be an easy change, but it will give us all the capabilities of AgileWiki3 for navigating time.
posted by Bill la Forge @ 5:33 PM
2 comments
2 Comments:
Hallo Bill. I am besotted by the rolons theory. Tried to figure something alike in the old 1984. In those days we had fewer instruments to deal with. Just COBOL and VAX/VMS Macro32 and RMS. Nevertheless we were able to produce packages that ran unattended (yes almost no maintanace at all) for more than 15 years. Some concepts where really alike: When, What, Protocol ID.
As for When and What they had the same meaning. We found very useful a sort of Protocol ID (a unique number like a "universal Time").
"Everything" entering the system for the firs time had a protocol-ID assigned that was propagated to all subsequent When and What.
From that moment we could find: all "whats" for each ID, all when for each ID and, of course all IDs for each when and what. Need to delete a document? Just roll back every when and what with same ID....
kahhht(at)supereva.it
Kahhhtt,
There is nothing new here. It is only a collection of ideas common to a whole lot of software, implemented as a framework.
I did come to a new understanding of late--Rolons should be kept small. I'm thinking of Rolons now as an alternative to beans. Persistent, configurable beans and built from a fixed suite of objects with only a little application code decorating things here and there. More on this when I get to defining the Roles of Rolons (typing, except that a Rolon can have more than one Role.)
Another small understanding that has matured of late has to do with links. In CowDb we had links between nodes. In COODBMS we have labeled links between Rolons, where the labels are the names of the Classifier sections holding the links. Anyone who has done any work with graph theory well knows how handy labels on links can be! So I'm reworking some of the queries (0.17.1 and 0.17.2) to help bring this out.
Now if you are truly besotted by rolonics theory, hey, I'm going to need a whole lot of help if this is going to go anywhere. Please get a sourceforge account and lets chat on the discussion forum at http://sourceforge.net/forum/forum.php?forum_id=367038
If this is going to be even a partial success, we are going to need a good team of developers behind it. And there will be no way to commercialize it if not enough folk are involved! (I have no aversion to making money.)
Actually, any kind of involvement would be appreciated. Things are too quiet. I try to make the wild claims and raise a bit of controversy, but don't get much reaction. (I do think the wild claims are largely true, but that's beside the point.)
Actually, I am convinced that I am sitting on a time bomb--this is (one form of) the answer the industry needs so badly about what good software should be and how it can be developed, even if my explanations and implementations are not always the best. But there is lots of work here. I'm not a greedy person and I know I need help on this. And we've all seen how something mundane like JBoss can provide good income. OK, new stuff takes a lot longer to sell and it will be another 3-4 months until I can begin to demonstrate this stuff convincingly. But it should be a lot of fun to put together a team to work on this, and it should pay handsomely as well.
Let's talk more!
--b
Post a Comment
<< Home