Changing situation

Starting to feel better, though I've had no time to rest. A series of job interviews at Fiorano. I've accepted a position there now as Director of Development. Then the big appartment search. Now we're packing and will be moving on Tuesday. Start work on the 6th, so I do have some time for a break. But I might not have internet access immediately.

Found a lovely old English cottage on a bit of land with lots of trees. A very cool and green place. So everyone wants to know why I still want an AC. But the wiring is good as well, so no problem. This place is in the Whitefield area of Bangalore, where the big IT push is occuring. Literally hundreds of highrise appartment buildings are going up. I can't believe we found such a fine place.

Bill

Not the most productive of times

Still getting over this cold, and both yesterday and today I'm buisy with other matters, though at least I got a release out this morning--the code has just been sitting there. :-(

Another drag is that our appartment lease expires the 31st of this month. Rupali has started packing and organizing, but soon I'll see a good chunk of my own time tied up in this activity.

Meanwhile, I hope you enjoy the new code. I figure the refactoring logic is now about 80% complete.

Bill

We are at an interesting stage

The AgileWiki is finally becoming quite agile, as well as very powerful. At this stage, I am much more interested in cleaning up the rough edges and fixing the known bugs. There are still so many additional capabilities that could be added, but I'd rather bring the whole thing up to production quality.

I then want to turn my attention (and I've been saying this for a while now) to applications. There really is so much that can be done with AgileWiki, we just need the use cases, hmm? I see AgileWiki playing well at both the personal level and for SMEs.

Wow! This is really an exciting time.

Bill

refactoring now updates wiki text

Feeling better today.

Release 3.5.0.11 handles the updating of internal structures (CSecs, inference deductions, etc.) during any refactoring operations (like move or rename). But it did not handle row content or wiki text.

The code just deployed at agilewiki.org now handles wiki text, but still does not update row content. But I think this is really good progress, yes? I'll note that none of the prototypes ever updated wiki text!

Now, being a first attempt, it doesn't do things with much polish. It tries to keep the wiki text the same, but when if must update it, then it just plugs in the full pathname. A bit ugly, that. Still I think it is a big step forward!

Now back to bed. :-(

Bill

out sick

mild sinus infection, but no sleep last night and nothing done today

This day too shall pass.

Bill

starting in on wiki text

Well, I've completed the logic to analyze and reorganize the information held in the citation structures for wiki text. Next step then is to start the logic to update the wiki text.

Now it turns out, rows also update the citation structures. So I also need to update row content, in addition to the wiki text.

Lots of work left, mm?

Bill

loop check, ? notation

A bit off this morning. My head still hurts from yesterday, the way it does when you've been studying too hard for too long. My mind has been wandering about, picking at odd things.

LoopCheck

When we create an include CSec, we check for loops that would give rise to unpredictable results (or an infinite loop, depending on how it is coded). So I've been wondering if the new refactoring code needs to do a loop check. Can we create a loop with a move or rename or what not? Likely not.

? notation

I can't see how refactoring can handle ? notation as it exists now. But if we allow only a relation (DU) name instead of a pathname, then it is possible. So it might be worth downgrading ? notation.

Bill

no more frAgileWiki, but...

The de, move, removeParent and addParent commands have now been updated and deployed at agilewiki.org. These commands, and rename, no longer break internal references. (WikiText being a different matter.) But there is a design issue that now needs addressing.

Depending on the number of deductions in an Ark, renaming a SemanticRelationDescriptorUnit can be quite slow. Fixing this means changing the output of the infer command and all the related logic. Something to keep me busy, I guess. :-( Likely I will get this done today and then do a release tomorrow.

As for updating wiki text, I think that is doable. One problem area is with the ? notation. Support for that will require additional data structures.

Bill

significant progress

I decided today to focus on two things: (1) the rename command and (2) undating all internal references except for wiki text content. A lot of code, and it looks like it is working just great!

Tomorrow the plan is to work on the de, orderParents, removeParent and move commands--all of these commands can cause broken internal references. Just doing this much is a significant step forward!

After that, I'll look into updating wiki text.

It looks like the beginning of the end of the frAgile Wiki. :-)

Gosh, it was fun. Why am I so tired???

Bill

The frAgile wiki

Because of the use of pathnames for internal links, there are many ways a user can break internal links. The uses command is a small step--it lists the internal links referencing a given rolon. But the rolons under it also have links which reference them. So even a simple rename operation can have wide-ranging consequences that are difficult to manage. This is an agile system, but also fragile. It is time to address this issue.

Bill

a step in the right direction

Well, it was a bit of work, and I found some bugs and made some improvements in the process, but there is a new command, uses, which should be a helpful addition to the Agile feature.

Uses lists all the various uses of a given rolon.

I have now deployed it all onto agilewiki.org. Tomorrow then I need to update the documentation before doing the release.

And then I want to think about having rename and move update all the uses. Now that should be fun!

Bill

Is it time for refactoring? Real Agility???

I'm thinking that all the TKS-level properties used in the implementation of AgileWiki are somewhat stable, especially with the completion of inferencing. So perhaps it is time to raise the IQ of the rename and move commands, and have them update references as needed.

This would add considerably to the overall agility. As it stands, things are pretty fragile. This would also be a big step in moving from beta to production.

Bill

Using inferencing in the documentation

There is a page for each Rolon class, and the Extends relation is used to define the relations between classes.

Also now there is a page for each command, and each command has a Scope relation that links it to a Rolon class.

Subclass is the inverse relation of Extends. And Command is the inverse relation of Scope.

See the Deductions LSec under UserGuide for the inferences that have been made. And yes, I've greatly toned it down. Seeing all the subclasses of a class or seeing all the inherited commands was a bit much!

The next step is to add the links to each rolon class page for viewing the subclasses and commands.

Bill

A "Duh!" Moment

I'm finally thinking from the perspective of an application developer. (What took me so long?) And I'm thinking, what happens if you delete an account or Application JSec? Or do a move or rename? Do we override these commands?

Stepping back from applications a bit, what about rename? It will break so many things, like includes. Right now, it is up to the user to use a half-dozen commands to check for various kinds of references. Agile? Not very! The least we can do is have one super command that checks for references of all kinds. (Small steps are good, as long as there is continued progress.)

Bill

2-time application JSecs

A 2-time application jsec (AJS) would have an effective date CEnt used for selecting and ordering. Default value would be the time of entry. Really just that simple.

As for a double-entry accounting application, its AJSs would have Debit and Credit relations to the various accounts.

Running balances for each account display gets tricky, expecially when you consider the effect of the snap/restore utilities. Remember that this is a 2-time item, so viewing past values of the current balance will not work! The simplest way is probably to have each account track its current balance, and then calculate the running balances by processing the AJSs in reverse effective date order.

Now consider if a bank used such a system, and entered the date when each check was written. Gosh, how much easier it would be to reconcile your checkbook!

Bill

Extends and Subclass

In /UserGuide/AwElements, I've now created a page for each Rolon class, and defined the Extends relation for all.

I've also defined the rules for deriving the Subclasses of a Rolon class. Ah! Better documentation through inferencing. (Or was that better living through modern chemistry?)

The next step is to create a Scope relation for each of the 85 commands, and define a transitive inverse relation, Commands. Then you can see all the commands which are applicable for a given rolon class. Hey, it keeps me off the streets at night. :-)

Bill

The short leg

One of the great things about Rolonics is that it makes it obvious when things are out of balance. I feel that AW is "stuck in the middle." With AW you can now weave very complex structures, but the simple accounting application is disfunctional. The problem is that AW has one short leg right now.

Rolonics tells us we need a balance between state, relations, behavior and history. In AgileWiki2, behavior was the short leg, and for all its capabilities it was actually quite limited. The behavioral aspects have been beefed up considerably now. But there is a problem with history.

Norm has always made it quite clear. We need a 2-time system. We need to be able to change the past, and lay out our intentions for the future. And the system JSecs are "in the way." I was too focused on the immediate problems with the implementation. But now I see the source of the problem.

There are two journals, methinks! There is the application journal and the system journal. Lately I've been looking at the system journal and observing that it makes for a very poor application journal. And for an accounting application, you've got to distinguish the effective date of an entry from the date it is entered--and that's the start of 2-time.

Another interesting thing is that the JSecs for a double entry accounting application is really a table, with one row for each account that is updated by that jsec. Hmm. Or perhaps it has a CSec for each updated account? Much food for thought here.

Anyway, it looks like we need a 2-time application journal. Could be interesting.

Bill

User Guide finished

Cheers! The User Guide at agilewiki.org is done, including a nice section on inferencing.

I'm thinking of doing a bit of documentation on the various Rolon types, next. Could be fun--I plan to employ some inferencing.

Bill

relations and inferencing

At this point I want to split the Semantics feature into Relations and Inferencing, as relations are simple and very useful, while inferencing is a tad complex and not so generally useful. I'm also interested in seeing where the rest of the user guide will take me, as it covers a key area that I have not given much thought to lately, i.e. applications.

3.5.0.8, descriptors

Release 3.5.0.8 is out and I've already found it helpful in identifying ambiguous links. As well, the Descriptors section of the user guide is done and I'm starting to think about the next section on tables. Should be interesting.

Bill

Tables as a feature

I'm working on the documentation for Descriptors and realized that about half of the commands are for tables. Hmm. I'm already planning a section on Tables, why not make it a feature that can be enabled by the view command?

Bill

resolution lists

With section 8 of the user guide, Classifiers, done, I'm thinking about resolution lists.

So far, names are always resolved to a single Rolon. That's not always the most helpful--sometimes you want a list. Case in point: Sue/Brother in the NuclearFamily example can resolve to any of the three brothers.

Fortunately, AW already creates the list when resolving names--but it then only uses the first on the list. So it should be easy to write a resolve command to list the rolons that a pathname resolves to, and to extend CurlyBraceNotation so that {Sue's BrothersI?Sue/Brother}, when clicked, would display a list of her brothers.

On the down side, I was ill yesterday with stomach problems. Likely a glass of fresh grape juice that I got at the Sun snackbar the day before. Feeling better today, but still a bit under the weather.

Bill

Section 7 of the UserGuide: Tags; changes to Descriptors

Just completed the Tags section of the UserGuide:
http://agilewiki.org/aw3/AwServlet?cmd=rid%20bcc8911dcdf6db99cfcfb8a52919b24b

This one was easy. But classifiers are next, and will perhaps be a bit more work.

I'm also thinking about changing the way descriptors work. At agilewiki.org there are currently 152 Cabinets, and most of them contain only a large DescriptorUnits Drawer. Seems like quite a waste of disk space, and it also means that they are largely out of date.

So why not make the Ark's own DescriptorUnits Drawer the default, and only use the DescriptorUnits Drawer in the Cabinets for DUs specific to that Cabinet? Sure would be easier to maintain!

Bill

Semantic Relations

Found a serious bug this morning in Semantic relations. Fixed it and deployed the code at agilewiki.org, so you can expect a release soon.

I've now started using semantic relations, so I don't expect any more suprises from that quarter, at least not such big ones. I've updated the /NuclearFamily example to show chained relations in the wiki text. (You can also do a chained relation in a go command pathname.)

Also in the UserGuide, each page now has a Next and a Previous relation for moving between pages. Works nice.

Meanwhile I've started thinking a bit about applications, and it looks like applications will be mostly GUI/Forms, as most of the heavy lifting is now handled by AgileWiki. Thinking of doing a PIM to illustrate this.

Now it is funny. It looks like simple semantic relations (like the Next/Previous in the UserGuide) is where the most benefit will be. I suspect that we will rarely need to use the inferencing capability, the exception being when there are a rich set of relations--like family relations.

Bill

resolving relations, ?query

If you look at the news on agilewiki.org, you will see that I've just fixed a bug relating to the use of relations. I'll note that I still haven't worked up any examples (today?).

Another problem folk may be having is that you need a reasonably up-to-date DescriptorUnits Drawer. Remember that this can be refreshed by deleting it--then it rebuilds it anew. For example, if you do a crRelationDu and it complains that the RelationsDescriptorUnitDescriptorUnit is missing, then this is the problem.

I still have one more extension I'd like to add to CurlyBraceNotation, a query: {?pathname}. When clicked on, this would list the matches rather than resolve to the first one. This could be very nice say, in the case of {?Brother}, where there is more than one result.

Bill

A real Semantic Wiki

I've just finished reintegrating the inference engine with the AgileWiki and it is looking just great! You can use the name of a relation (infered or otherwise) as a WikiWord. And you can use relation names anywhere in a pathname, so you can chain relations: Fred/Mother/Brother.

Should be a lot of fun, and very helpful for applications. :-)

Bill

inferencing--further clarification

The best solution for the output of the inferencing engine is to keep the rows representing various relations. Only we need to add a property to connect each subject or object to that row.

Then we need to add a query like relations which lists the infered relations that a Rolon is participating in.

Bill

integrating the output of the inference engine with the wiki

Currently the infer command simply creates a table of infered relations. I do not think that is good enough. Rather, we should attach properties to the various subjects of those infered relations. Then we can easily access the results, and the change to name resolution will be small and fast.

As it stands, name resolution would need to search all the many rows created by the inference engine. And that's not good.

Now, I really want to support multiple inferencing systems, and this becomes easy when attaching the output to the subjects. Then name resolution has immediate access to all the inferences which apply to that subject. This is important, as we want to keep the infoset of each inferencing system reasonably small, though multiple inferencing systems may have considerable overlap.

Fun stuff!

Bill

CSecs have been reworked

CSecs now use pathnames rather than RolonIds, which will be helpful when Cabinets become mobile. I've also rebuilt all the CSecs at agilewiki.org.

The next project will likely be to complete the integration of inferencing. But I'll probably work the user guide a bit more first.

In any case, you can expect to see a release soon.

Bill

Documentation on Agility

Release 3.5.0.3 is out, and a new chapter of the user guide as well. This time the topic is agility:
http://agilewiki.org/aw3/AwServlet?cmd=rid%20c62936362550a06b8f48f2e27caf6a81

So I'm thinking that it is time to get back to the code and fix the CSecs.

Updated UserGuide: Time Navigation

http://agilewiki.org/aw3/AwServlet?cmd=rid%2095aa83f0078249c758707071df85e6ad

New page on TimeNavigation. This one took a while, as there was so much that needed fixing.

Expect a release soon!

Bill

snaps done, work to be done, versioning

The fix for removeUser has been released, the documentation on Access Controls has been documented and the update for rebuild has been deployed on agilewiki.org. Great progress.

The final utilities are dump and restore by cabinet, to allow cabinets to be moved from one server to another. This also requires the RolonIds to be changed, otherwise you can not restore a cabinet once it has been destroyed. It also requires CSecs to be reworked--currently they use RolonIds, which means you can not determine what has happened when destroying a cabinet breaks a CSec reference. All this is coming, but perhaps not right away.

Also I need to work on a number of known bugs before we can call this production.

Another project is sharing cabinets between servers. And another is adding email. There really is a lot of work to do if we are to cover everything handled in the prototypes!

I've also been thinking about replacing all the GUI. It needs it! But more on that later.

And then there is additional integration with semantic references and wiki name resolution. That one should be a lot of fun.

But right now I'm thinking of something small, versioning. I want to break it out as a separate feature in the view command and then write it up. Otherwise I fear that versioning will be lost in with all the Agile stuff. And versioning is one of the more expensive features from an implementation perspective.

Bill

remove user buggy, not missing

Turns out there was a bug in the applicability logic for removeUser. I'll likely release this today, after finishing the latest section in the user guide.

Bill

remove user command is missing

I was writing about virtual wikis and access management today and I just fell into a hole. You can add users to a user group, but you can not remove them. Woops!

Gosh, that's two bloopers I found today. At least this one should be an easy fix... tomorrow. It is good night for now. Or, er, Rupali wants the computer. :-)

Bill

CSecs vs Cabinet Mobility

I goofed.

In AW2 we had the ability to move cabinets between servers and never referenced a Rolon Id across cabinets. Oops! CSecs in AW3 do just that. So we will need to change them. Oh well. I don't thing there are too many CSecs just yet.

Bill

Ads on agilewiki.org

Well, I've gone ahead and put google ads on agilewiki.org, as it is a source of income for open source and I'm now working full-time on AgileWiki. But I don't expect much and will likely earn even less. The traffic just isn't enough and the return rate is pretty small. Comes under the category of leaving no stone unturned, methinks.

Not that I need a lot, as Rupali and I will be relocating to Raipur, India at the end of the month. $50/month would be great. But we'll see. What's really needed now is content. And I tend to focus too much on code.

Bill

snap done, restore is next

Doing a snap/rebuild reduces the 55MB database down to 11MB. And because each cabinet is snapped out as a single transaction, the rebuild takes about a minute. (The smaller size is also a significant factor in how long it takes--probably all runs in ram.)

Now I've done the testing by editing a snap file to make it look like a log file. The next step is to upgrade the rebuild to work with a snap file and a set of log files. Tomorrow, thankyou!

Bill

snap thoughts

In AgileWiki2, the snap utility was simple. It created a log file which reflected current state (no history) and then you rebuilt the database using only that log file. This let us keep the database to a reasonable size, though at the cost of losing all history. Good enough for a prototype, but there are situations where it simply will not do.

What you really want is the ability to create a snapshot for an eariler time, like the beginning of the previous month. Now you can keep some history. And this is important when sharing content--sharing depends on the change history.

As for how to do this, I'm thinking that the snap utility should be kept as simple as possible--it just creates a log-like snap file reflecting the state of the database at a past time. Then the restore utility uses the snap file together with selected content from the log file to create an up-to-date database with limited history.

Seems doable.

Bill

more documentation: SimpleWiki

http://agilewiki.org/aw3/AwServlet?cmd=rid%20066901edc338384daab120261d951bbb

I've added documentation on how to use the AgileWiki as a simple wiki--see the above link.

Bill