lets make it faster

The AgileWiki is built on its own database, tks, which builds in turn on bsddb from Sleepcat Software. Tks uses the transactional facilities of bsddb. And the worst thing about the AgileWiki is that it is so slow.

It can be made faster.

The interesting thing about tks is that it only records changes--nothing in the underlying database (bsddb) is ever changed or removed. So it should be relatively easy to keep tks reliable without using bsddb's transactional facility.

Two things I would preserve in tks:

1. the tks api and
2. the bsddb content.

This pretty much isolates where the changes need to be made.

2.1.4.2 limits

We've now got magic. Once you configure some topics with TagMatch, the namespaces of those topics (think vocabulary) get added to an topic with the matching tags. Now you can create topics and attach vocabularies just by adding the right tags. And that means that any WikiNames in the topic will be resolved using those selected vocabularies.

So if you have a biology namespace and a chemistry namespace, add the biology and chemistry tags to topics on biochemistry and bingo! You get a custom namespace.

Now the problems Norm had with 2.1.4.1 were circular tag matches. I did a heavy-handed fix in 2.1.4.2, and in addition to preventing recursion within the inverted tag match logic, I also cut off includes from the namespace of the TagMatch topic. So you only get the namespace derived from that topic's structural context. Oops! I'll use a smaller hammer in the next release and fix that.

Resolving References in a Journal

I've talked before about having both organized (structured) topics and classified streams of topics. Ah yes, now we will be supporting multiple streams of unorganized (but classified) topics--we're calling them journals. But there has been something missing.

A Wiki Topic needs a namespace to resolve its WikiNames. No problem in most Wikis, all names are global. And no problem for organized topics in the AgileWiki, as a topic inherits (and modifies) the namespaces of its parents. But what about journals? Must each journal entry depend mostly on its parent (the journal) or itself for the namespace for resolving WikiNames? Perhaps we'll have many journals, each with its own namespace?

There's a better answer. We actually do know a great deal about a properly tagged journal entry. Consider the topics with TagMatches--they are kindof like the parent topics in a structure. OK, then let the journal entries inherit their namespaces based on their tags from the topics with matching TagMatches.

Lets consider a journal entry which deals with several different realms of knowledge. It then has tags which identify those realms, and there should be [structured] topics in those realms with TagMatches referencing those same tags. Bingo--the journal entry can resolve all its WikiNames using the namespaces of those topics.

Previously, we addressed TagMatches as a means of accessing a selection of unorganized topics. Then we named streams of unorganized topics: journals. Now we're using the inverse relationship defined by a TagMatch to provide namespaces for those unorganized topics (i.e. journal entries).

journals

Ever keep a project journal or a personal journal? Its a log of what's happened, notes and anticipations.

The cal Cabinet is, of course, a great place for a journal. But sometimes you want to have more than one journal. To this end, we need gencal to create the same structures in a different cabinet. But that is a LOT of structure! So we'll exclude days, and instead support weekly journals.

Now does this mean we need a lot more cabinets? Well, there is no reason why we can't add a journal to an existing cabinet. Now, potentially, each cabinet can have its own journal.

Now, can I send email to a particular journal? Sounds good. If the destination of an email is a cabinet with a journal, then we should post the email to the appropriate week.

I'm also thinking that ArkConfig and cal should be combined--you can think of cal as the Ark's journal.

And what release does this all go in? How about 2.1.4? These are small changes compared to developing the advanced interface.

Why the sudden interest in Journals? Well, journaling is one of the underlying themes of Rolonics, from which the AgileWiki is derived. And it seems like a mobile phone is better for journaling than ledgering (where by ledgering I mean updating Topics).

mobile difficulties

It looks like the mobile browser Norm is using does not support default (initial) values for text boxes, making it darn difficult to edit something.

I can think of at least one workaround, but its prbably best to try another browser first.

--I'll keep you posted.

Mobile interface, quick and dirty

The new mobile interface has been pre-released, sans documentaton, on AgileWiki.org. If you're a power user, feel free to try it--just set your default interface to mobile via a PC first.

Norm already reports that he is using it.

You can expect a more formal release later today, IST.

mobile interface?

Norm has been raving about his new phone that he browses the net with now. So this is a good opportunity to try creating a mobile interface, why not!

The mobile interface will be based on the power interface, but have a stripped down top part and no tags displayed. Also, apparently a button is needed for the command-line.

Shouldn't take too long. :-)

cleaning up tags

1. When tags are displayed, they should have the same format as used by the tags display, i.e. replace '=' with ': '.

2. Tags are of no value to guests. Don't display them.

3. Inherited tags are of no value to basic users. Don't display them.

These changes will be included in the next release. And yes, I'm starting to think about the expert interface which gives users the ability to add/change/remove tags as well as search on tags and add tagged topics to a namespace.

time off for dirty dishes

Got a book yesterday. I needed a break from code. Read half of it--and was up quite late for me.

Yesterday also the maid took the day off. Rupali says it will be a 3-day break. I'm up to my knees in dishes. Running out of silverware. Its a priority.

So it looks like I'm taking an extended holiday. I've also got the itch to review the documentation.

4 columns of commands!

Well, I've had a busy morning working on the last of the code for the master interface--generating a 4-column display of the applicable commands. But I finally got something that looks OK.

Still to do the documentation. After the release I plan to veg out for a while.

Its been fun.

master interface roughed out

Well, I'm close to releasing 2.1.3--master interface. Its working, but the list of commands goes on for three pages. That's just too much scrolling! And I'm all tired out.

Tomorrow I'll go with a 3-column display, like I did with the basic interface. 'Cept this one is generated on the fly. :-)

2.1.2 not recommended

The advanced user interface, in 2.1.2, just got harder to use. I expect that Norm, being a real power user, will love it. All the helps have been removed, using a lot less vertical space.

This "advanced" interface is strictly a power user interface. And it will take some time before I can create another interface which extends the capabilities offered in the basic interface. So here's the plan...

I'm going to first rename the advanced interface to be the power interface. Then I'll introduce the master interface--this interface will not take too much time, as it is just the power interface with lots of helps. There will then be 4 interfaces: guest, basic, master and power.

Think of the master interface as training wheels for the power interface. Unfortunately, friendly interfaces like the basic interface take quite a bit of time to implement. So if you want to work with tags or extend namespaces, you are going to need to use the command line interface for a while.

Not frames, but iframes!

OK, so I'm a bit slow some times. IFRAMEs are easy, once you've come to understand how to use frames.

And the back button works!

Looks like there will be a 2.1.1.8. :D

IFRAME?

In doing 2.1.1, I learned a lot about frames. So now I want to try an iframe implementation. Again.

I'd rather do this now while I have only one frame-based interface.

I don't like having a broken back key. :-(

Bill

A Free Web Site

If you look at AgileWiki.org/wiki/cc/Home/BillLaForge, you will find my personal Drawer. The same applies to every user of AgileWiki.org--and no one can modify these Drawers except for the user/owner.

In effect, everyone gets a free web site.

Final release of 2.1.1 is out!

2.1.1.7 is released but not installed. (Later!) But I also managed to clean up the project page at compstrm.sourceforge.net.

Enjoy!

tired, perhaps in the morning...

I am hot to get the release out, but beat. Went shopping tonight. Foodworld finally had some frozen chicken in stock. (The fresh chicken smells like old fish.) Stayed up late to talk to a coworker in Calif, but I guess it was too early still for him. Going to bed. Hopefully I can wrap this thing up in the morning.

I miss Rupali. Her mother was in intensive care, but is better now. She should (Should!) be home in a week, but her ticket is not yet confirmed. :-(

code complete for 2.1.1

Finished the code this AM for the basic interface, specifically the mvthis and this commands. Just need to update the documentation, release and install.

changes to the default display and advanced interface

Just tired tonight--not a good time to code!

I did have a nice chat with Norm. We walked through the basic interface and touched on mvhere. I also raised the question of simplifying the advanced interface header, stripping off the top bar and the tags. He agreed. This frees up a lot of vertical space!

What I'll do with the tags display is add it to the default display of a topic. This means it will not be visible when viewing the results of a query, but that should be OK. It also means that guest and basic users will now see the tags, which is probably a good thing if a mixed blessing.

Timing is the question. Probably I'll work on this between 2.1.1 and the new advanced interface (aka 2.1.2), because advanced users definately need to see those tags.

2.1.1 nears completion

The mvhereCmd has been released. Finally, the basic browse capability has some utility.

I've also delayed posthereCmd and postthisCmd to 2.1.2, so all that remains of 2.1.1 is mvthisCmd and hereCmd. :-) And, of course, some updates to AwDocs.

Once 2.1.1 is complete, I'll install it at AgileWiki.org. Then finally I can finally claim that the AgileWiki content is easy to reorganize--even without having to be a power user.

getting close

Actually, I'm finally ready to start writing the code for mvhere, having completed and tested the mvhere form and the applicability rules.

Its taken a while, as this is the first dual context command I've worked on and of course, nested frames are new too.

The actual mvhere command should be easy--its a simplification of the mv command, without all the checking that is handled in the mvhere applicability rule. (Applicability has gotten pretty complex. Fortunately the work is done for the user in the basic interface--if the command is not applicable, the command is dimmed. On the other hand, with the advanced interface, the user gets an error message after trying the command, or the user can first check the various helps to see which commands are applicable.)

some progress on mv

There will be two move commands, mvhere which moves the top-level topic under the browser-level topic, and mvthere which moves the browser-level topic under the top-level topic.

I'm working on mvhere first. Currently I'm working on the applicability rule. Its going slow.

On the other hand, I am keeping up with the laundry, shopping, cooking and dishes. And looking forward to Rupali's return.

binocular vision

With the browse capability you can now view two locations in the Ark at the same time. And with that I conclude a busy but fruitful weekend.

Posting (copying) and moving is coming soon, but perhaps not real soon.

I'm also looking forward to a new advanced interface that will cover tags, time navigation, descriptors and classifiers. But I suspect there is still pleanty of work left to be done on the basic interface.

Enjoy!

nested progress

With frames in place in the basic interface, I've got a good setup for experimenting with recursive nesting. And I've learned a few things...

One thing I've learned is that duplicate frame names don't cut it--target always goes to the first named frame. And the rule of thumb seems to be, if the browser can't resolve the target, it just opens a new window.

Another thing I've learned is to use _parent as the base target for the nested group. A target of _self gets you the same frame, while a target of _top is the outermost frame.

Finally, the browser back button tends to get confused. It doesn't always remember that an entire group got canged and often just updates the current frame. :-( Conclusion: avoid the back button. (I did have some thoughts about providing my own mechanism some time back, guess I'll be thinking more about them now.)

Otherwise things seem to work as expected. Now I just need to make it work. :-)

recursive nesting

Many commands involve more than one location, mv and post being good examples. With the basic interface converted to frames, we can now do recursive nesting rather easily, just by putting the whole web page in the content frame. With this we will be able to browse while still keeping our original place... Its a start, anyway. But after that doing a mv or post (or include or name) is easy. Of course, we'll want the command list on the nested web page to be different from the outer page's command list. :-)

basic frames

I don't want the guest interface to use frames--its nice and simple and indexes quite well. I do want to add titles, either from a title tag or using the WikiName in the abscence of a tile tag. That should help the indexing a bunch. I also don't want to mess with the advanced interface.

On the other hand, the basic interface is just perfect for frames. The result is pretty nice too. I only made a minor change to the server and it works without impacting the other interfaces.

But more work is needed. The main problem is that because of the heavy use of the session object, I can't seem to handle two requests on the same session at the same time. But it shouldn't be too hard to serialize them.

A lessor problem is that the server does a lot of redundent processing when handling a framed interface. But I can fix that later.

Adding frames to the basic interface is a nice improvement, but it also gives me an easy way to handle partial-window updates and, much more interesting, recursive nesting. With recursive nesting, I should be able to support a browse capability when doing a move or copy.

So it looks like I'm moving away from AJAX-like capabilities and using frames instead. Frames seem to be the best fit for this. I can always use AJAX techniques later for an integrated chat capability--that could be nice!

Baring any additional problems then, I should have a release this weekend.

here lie dragons

One nice :-( thing about the web. If you get something to work with one browser, it often will not work with another.

Today I found that when I stuff the innerHTML of a div, I can't seem to navigate it. Which sure makes using focus difficult unless you're using frames or iframe. Then in the source document you can do an onfocus.

I also learned that iframe ain't so great. target="_top" seems to open another window. Possibly things work better with frames?

I've still got a lot to learn, methinks.

fun with XMLHttpRequest

Now I want to read the sf logo asynchronous using XMLHttpRequest, mostly just to get familiar with it.

First, I want an asend method that I can invoke like this:

asend('get','/sflogo.html',loadlogo)

This says do a get asyncronously to /sflogo.html, and call loadlogo with the response.

function loadlogo(ro){
document.getElementById('sflogo').innerHTML=ro.responseText
}

This approach gives me pretty good code reuse. Here's my first draft of asend:

function asend(mode,action,go){
var ro;
var browser=navigator.appName;
if(browser=="Microsoft Internet Explorer"){
ro=new ActiveXObject("Microsoft.XMLHTTP");
}else{
ro=new XMLHttpRequest();
}
ro.open(mode,action);
ro.onreadystatechange=check
ro.send(null)
return true;

function check(){
if (ro.readyState==4){
go(ro)
}
}
}

Probably a few improvements are needed. But it works for now.

I did find that the target element needs to be a div, not an iframe. Nice thing is, div looks better for this application.

adventures with IFRAME--delayed load

Norm and I have always had a conflict. I wanted the sflogo at the bottom of the page, and he wanted the cursor positioned at the command line. He had to wait for the logo to be downloaded on every page before the cursor was positioned.

Resolving this conflict was my first use of IFRAME. I put the logo image html in a separate file, sflogo.html and an empty iframe at the bottom of the advanced interface template--advanced.html. Then on load, instead of positioning the cursor, I called an init function which (1) positioned the cursor and (2) replaced the content of the iframe with "/sflogo.html".

Bingo! No more conflict.

Hey, this stuff is all new to me. Gotta start simple.

a redirect for now

I've just put a redirect at compstrm.sourceforge.net to point to the AgileWiki Cabinet at AgileWiki.org, pending my request to sourceforge to change my project home page location.

Worked too late last night installing 2.1.1.2 on AgileWiki.org, got up late and off to the office soon. Not much time this morning to do anything but add that redirect.

AJAX Simplified

Here's a quick tutorial that seems to cover everything I need to do (currently):

85-Rasmus-30-second-AJAX-Tutorial.html

IFRAME Complications

It would be great to use IFRAME for non-navigational command responses. We could then easily use template files for each form. :-) The complication when using a command line interface then, is in selecting the destination. :-(

This likely needs to be done by client-side JavaScript, by processing the server's response. Sounds like a hidden frame is needed. In for a penny, in for a pound. Perhaps is would be best just to implement AJAX. :-(

Again, the motivation here is to avoid having to need two windows for commands like mv, post, name and include.

Anyone familiar with AJAX? :-)

It is quiet here

Rupali left for Raipur last night, a day later than planned. The kitchen is piled high with dishes. If the maid doesn't get here soon (she normally arrives after I leave for work), then I'll just have to do them myself.

I've now restructured an introduction in AwDocs, using content from both the AgileWiki project page and the AgileWiki introduction web page. Still some odds and ends to do, but it is getting close to a release. (I also want to fix a very minor bug in mv.)

I'm thinking of moving the project page to the ReadMe Cabinet:
http://AgileWiki.org/wiki/cc/ReadMe
But that will be after this next release.

IFRAME

For an easy to use version of post (copy) and mv (move), I want to use IFRAME to facilate destination navigation. That should be a lot easier than using a second window and then copying the destination pathname into the command line in the first window.

But why not use IFRAME for command output? Then queries can just update the one frame. Eventually we could add a more capability for when there's a lot of output. (This would fit nicely with AW's streaming capabilities.)

No, its not AJAX. I'm just cherry picking.

Another conference?

http://www.linuxasia.net/

This is aparently another OSS conference, this time in New Delhi in February.

Decisions, decisions. Should I go?

Your comments could be helpful!

Bill

time out

All work and no play must make for dry documentation.

Went to the Forum mall last night with Rupali and her brother, Sanjay. Got a book on JavaScript, as well as another SciFi novel. But I'll be back pounding on AgileWiki Docs soon enough.

guest and basic now documented

My brother Sanjay is down from Raipur. He came to buy some horses for the Raipur Police department--mostly for ceremonial purposes. He returns tomorrow with my wife, Rupali. So it looks like I'm on my own for a few weeks.

Meanwhile, I have managed to document the guest and basic interfaces. But before I do a release, I want to simplify the AgileWiki intro page, moving much of the present content into the AwDocs Cabinet. Then back to finishing the basic interface.

I've been playing with the basic interface, of course, and found a few things I like about it. Like, upArrow, downArrow, PgUp and PgDn all work without having to hit the tab key first.

I also like having less vertical space taken up by a large header. But what I don't like is the height of the left hand column. I'm very tempted to list 2 links per line.

AgileWiki is now live at AgileWiki.org

There are still references to CompStrm and CompStrm Ark. Some I'll fix in the next release (like the ones on the UIs), and some will be left (AgileWiki internals, compstrm.sourceforge.net).

Guess its time to work on documentation for a while, before continuing with the remainder of the basic interface.

Name Change Mania

First it was the project name change, CompStrm Ark => AgileWiki.

Then it was the domain name change, compstrm.org => AgileWiki.org.

Then it was the blog name change, The CompStrm Blog => The AgileWiki Blog.

Next came the release name, zip file name and directory name changes, compstrm2.1 => AgileWiki2.1, complete with script updates.

Now I'm working on changing the Cabinet name and some of the Drawer names, CompStrm => AwDocs, CswCmds => AwCmds, etc., and related code changes.

:-(

Consistency is the hobgoblin of small minds. Of course, consistency does make things a bit easier for new users. Sigh.

Updated Home Page

I've just reworked the introduction to AgileWiki on the project home page. You may find it useful, especially the section on "7 Kinds of Topics": http://compstrm.sourceforge.net/

A New Name

My ISP just confirmed that I now have the name agilewiki.org and I am in the process of changing the product name from The CompStrm Ark to AgileWiki. (I was planning on rewriting the documentation anyway.)

basic interface is out!

The 2.1.1.0 release may be one of the more significant releases, as it includes the new guest and basic interfaces. (The layout for these two interfaces is now quite similar.)

My sincerest desire is that this will prove to be a major step in making the Ark easy to learn. Every command supported by the guest and basic interfaces is accessed via clicking, with forms in the basic interface for entering topic names. (No {braces for spaces} required.)

The guest interface, as before, only provides some simple navigation facilities. The basic interface, for now, supports content creation, changes, and renaming, as well as some additional navigational aids. So there is nothing here that should prove difficult. Indeed, from the perspective of the basic interface, the Ark looks like a simplified Wiki.

My thought is that some users will only be browsing topics, and others will just be adding content or just comments (remarks). But for those with more interest, these interfaces give you a chance to get oriented and learn the basics before having to deal with a command line interface.

a generic table descriptor unit

Work on the basic interface is going well. I expect to do a first beta release tomorrow, after which I want to spend some time updating the documentation.

I am also considering the addition of a generic table descriptor unit to the CabinetDescriptorUnit and the DefaultDescriptorUnit. This then would allow for the creation of tables even using the basic interface, though without pre-defined columns. This would require an enhancement to the crc command implementation.

One concern here with ongoing enhancements is that rerunning crc might remove existing entries to the NewTopicNameMap in various DescriptorUnits. My thought here is to add some additional logic to merge the generated entries with existing ones. --A consideration that is important for administrators who are already defining their own DescriptorUnits, if not now, then in the future.

AJAX Anyone?

While I was at FOSS.IN, someone said that I should look at AJAX. I did. Fabulous technology. I've gotta use this!

But not right now. But then, I don't mind stealing a few ideas, if only the use of IFRAME. (I expect to have quite a bit of fun with the beta 2 release of the basic interface.) :D

Too many interfaces?

I'm now planning to have the following user interfaces:

1. guest,
2. basic,
3. advanced,
4. expert,
5. master and
6. power.

This will allow users to learn the Ark in easy stages. Power is the old interface, but without wasting space on help or command lists. Master uses a command line interface like power, but with a list of helps down the left side.

Guest, basic, advanced and expert then are all click interfaces without a command line. Expert will have most of the commands, some commands and options being left out as they are best handled with a command line interface.

Guest is browsing at its simplest, while basic will support creation, maintenance and reorganization. Advanced then introduces namespace management.

And yes, things are progressing nicely. Only a few more days now until a first release of basic. ;-)

basic progress

I'm getting close to a release on the new basic interface (and a rewritten guest interface). All that remains to be done at this point of the original intention is the implementation of forms for crd, crf, crp, crls and crr.

However, I've also extended the intention for 2.1.1. In subsequent releases I now expect to provide selection forms for promote and demote, and browsing for move and post.

The idea here is that using only the basic interface, you will be able to create, change, destroy and reorganize content. The subsequent advanced interface then will add namespace management.

junking the guest interface

The new basic interface looks a lot nicer than the guest interface. It has a column on the left side for login/logout, general links and commands. So I've junked the current guest template and I'm replacing it with a simplified version of the basic template.

One advantage of this is that there is much less of a transition when you log in. Eventually I plan to build the advanced interface template in the same pattern, leaving only the power interface in the old layout.

on Foss

The foss.in conference ended yesterday. And I was glad to be a part of it.

I learned two things at FOSS:

1. There is a real interest in an agile wiki. The difficulty of refactoring wiki content is well known.
2. The user interface to the Ark is just too big a speed bump. Without a major effort in this area, the Ark can not be used to build communities around content.

So I cranked out the guest interface, a step in the right direction. But only a small step. I expect to be spending a lot of time working on version 2.1, making things easier to learn and understand.

I've spent the day working on the new basic user interface, but it will take more than one day to develop. For example, you can't just have a "de" link to destroy a topic--that's too hostile. For a click-based interface, some things need to be confirmed.

Documentation will need to be reworked once the basic interface is in place, especially the introduction page for the Ark. And on the project page, I want to spend more time talking about the Ark as an agile wiki and less time on Rolonics.

One thought I've had is that with typed topics, you can have type-specific help. But that will come later.

elective interfaces

I'm just about finished the guest interface. No command line, indeed there is nothing to type--you just click away with your mouse.

After that I'm thinking about having 3 more interfaces: basic, advanced and power, with a facility to change from one to another. (The default interface for a user being specified by a tag on the user's Drawer.)

The basic interface would still not have a command line. Rather, forms can be used for entering a topic name when, for example, creating a page. (From the basic interface, a user can create topics, destroy them or edit them.)

The advanced interface re-introduces the command line, but still with a reduced command set. With this interface a user will be able to work with tags and headers, but not with other classifiers.

The power interface then will be the old interface, but with a stripped down default display.

The fun part will be to structure the documentation to support the various interfaces, carefully leading the user from basics on to more advanced topics.

2.0 is finished, what's next?

A lot of capabilities were added in version 2.0. We've added DescriptorUnits, access control, roles, home Drawers, tags and tables. I've call this the ugly duckling stage, having added a lot of complexity without a whole lot of benifit. Overall, the Ark has gotten harder to use.

Now it is time to build on these capabilities, and focus on making the Ark easier to learn. It is fine right now for the power user--the Ark is easy enought to use if you use it several hours every day. What's needed is an alternative front end for the novice user.

Lets start 2.1 off with a simple interface that has no command line. This would be the default interface for guests. Other users will be able to toggle between the two interfaces. Later we can develop a middle-ground, a comman line interface that is a bit easier to use.

A home Drawer for every user

I've just revised the specs for 2.0.17. Finally, every user will have a Drawer to call home. Or just a place to put your socks? :-)

imatch

IMatch was a user request (from Norm) which I'm finally getting around to implementing.

IMatch gives you the same capabilities as include, except that it works with tags. Its usefull when you want to include a lot of Topics.