Friday, June 30, 2006

AgileWiki3 persistant data structures now documented

At http://agilewiki.org I've now completed another cabinet, PersistantDataStructures. And it is, if I say so myself, quite readable. I expect this will be quite helpful when trying to work with the AgileWiki API.

Bill

Wednesday, June 28, 2006

Content!

We now have a fair amount of content at http://agilewiki.org

There is user documentation, a comprehensive list of open issues, and even the layout of the logs file is documented.

The database is doing OK. It crashes occasionally, but without dataloss.

Still much to do. I'll note that the developer list is continuing to grow--there are now 15 of us all told. Contributions are coming slowly, but then there's not a lot of documentation yet to help folk get started.

So there's a lot to do. For now, I'm still the bottleneck but I'm working hard to get out of that position.

Bill

Monday, June 26, 2006

a bad release

There's a problem with release alpha28-1, as the AwServer.jar file it contains is not up to date.

So I'm doing release alpha28-1a. :-(

Bill

Sunday, June 25, 2006

AW is starting to stabalize.

Well, we're still not yet at beta, but it looks like agilewiki.org is reasonably stable.

I just put out a bug-fix release, alpha28-1. This fixed 5 bugs I found over the weekend, including 2 which were causing AwServer to crash.

So its back to adding content. There is ever so much that needs documenting, no?

Bill

AgileWiki3 defined, finally

I've finished, for now, the OpenIssues cabinet at http://agilewiki.org/aw3/AwServlet -- this has become a comprehensive list of everything to be done in AgileWiki3.

Feel free to add your comments. :-)

Bill

Saturday, June 24, 2006

back to debugging for a bit, a big step forward

I worked on the OpenIssues cabinet this morning and found 4 bugs, one serious. But no dataloss, so at least there were no critical bugs. Guess its back to debugging for a while.

This is not what I hoped for, but still release alpha28 is one of the better releases. Things are definately improving--AgileWiki is at least usable. And now finally there is some content, which is really a big step forward. (Its hard to learn how to use it without content!)

Bill

Time to start using AgileWiki3

Alpha28 is released and can now be accessed at http://agilewiki.org/aw3/index.html

So its time to start using it and see what breaks. Already I've noticed a caching problem when editing tables. Oh well. I'm sure there will be other things.

Bill

Friday, June 23, 2006

Found/fixed a big hole in the database

Hopefully now AgileWiki will be much more stable, perhaps good enough to go Beta? We'll have to wait and see. Fer sure, the code is quickly approaching beta in functunality.

Meanwhile, we've been defeated by Tomcat. :-( We could not work out how to bring up a war file as root.)

Once the new release is out, we'll get agilewiki.org back on line, though I expect the URL will be something like http://agilewiki.org/aw3 rather than http://agilewiki/AwServlet.

Bill

Thursday, June 22, 2006

a change of plans

I now have a reproducable database crash. This gets priority over all else.

Oh, and Nuitari and I have been trying to reconfigure agilewiki.org. So its down until I get back to it, looks like.

Bill

Wednesday, June 21, 2006

a mid-week release?

OK, I've shaken down the rebuild facility, updated the README files and started entering content. And it just works great.

So I'm very tempted to do a mid-week release and start building countent at agilewiki.org.

Bill

Sunday, June 18, 2006

The rebuild facility is now complete, next steps

Each time you start AwServer, it creates a new log file--log file names include a timestamp. We now have a facility (to be included in the next release) to rebuild the database from the log files. Of course, in the process several problems were found/fixed in the code that creates the log files. (AwServlet/README.txt contains the instructions on how to do a rebuild.)

So at this point we may have enough to be able to build (and retain!) content. The theory is that if the database goes bad (which it still tends to do), we can just rebuild it. That's theory--we still need to see how that works out in practice.

So the next step is to try building some content. Then I guess the next priority would be a verify program that does a simple integrity check of the database.

All in all, things are looking reasonably good. I figure we are only weeks away from beta. :-)

Saturday, June 17, 2006

User documentation now available on-line

With the release of alpha27, user documentation is now available on-line at
http://agilewiki.org/AwServlet/userdoc/index.html

And with the basic wiki capabilities now in place, my attention is then focused on the the rebuild facility. Once that is done, it will be time to work on some initial content and the overall reliability of the database.

Bill

Friday, June 16, 2006

laying the groundwork for the restore utility, the upcoming release

I've just started the restore utility, which will create a new database from scratch using the log files. So don't expect this utility to be working in the next release!

I've also promised Nuitari that I'd see what I can do about changing the URLs for the servlet. I'll be working on this tomorrow and consequently delaying the release until I finish that.

This will be a good release. The basic wiki is quite functional now, and there will be a reasonable amount of user documentation available on-line. Once the restore utility is working, we need to focus on making it agile again.

I'll also note that the team keeps growing. One new member, Niall Loughnane, has written some documentation that has been saved at http://agilewiki.dev.java.net (under documents and files).

Bill

Tuesday, June 13, 2006

documentation!

Well, I finally went and wrote some documentation--about 8 web pages, all checked in under subversion on java.net.

These are brief descriptions of various high-level topics. Should be helpful for new users.

Bill

Sunday, June 11, 2006

pretty much finished the basic wiki capability today

Renamed the roles command to be names, as it lists all the accessible named rolons.

But the big news is that the cit command is now working. This command lists all the rolons which have a reference to it. And this completes the basic wiki capabilities. This is a bit tricky, as a reference can either be by name, relative pathname or absolute path name. And since names are not unique, references to the current context only count if they actually resolve to the current context. (The first time I implemented this logic, several years ago, it was a lot more than just one day's effort. This time it was a snap, and a whole lot faster than any of the previous implementations. But then, this is one of the features that the database was designed to handle.)

Now my attention turns to database utilities, reliability and the like. And then we move to beta and start working on all the advanced features. Finally!

Bill

Saturday, June 10, 2006

roles, pathnames and go

I've been busy today.

There is a new command, roles, which lists the visible topics and LSecs.

There is a go command which accepts relative or absolute pathnames, where the first name in a relative pathname can be any role listed by the roles command.

And brace notation now works with pathnames.

Tomorrow I plan to work on citations.

Looks like the start of a great release for next weekend. :-)

Bill

Friday, June 09, 2006

brace notation, pathnames and LedgerSections

This morning I completed the implementation of the full AgileWiki2 brace notation, except for pathname and lsec references. So for example

{topic name} will be a link to the topic, even if it is not a proper wiki name.

{{WikiName}} will NOT be a link to a topic, even if it is a proper wiki name.

{sf|http://www.sf/net} is a link labeled "sf" to the sourceforge site.

So the next step is to enhance the API to support pathnames and lsecs. And we might as well add a goto command too.

Bill

Thursday, June 08, 2006

getting closer to beta

This morning I dropped the crTopic command in favor of the new crDrawer, crFolder and crPage commands. I think the result gives you something closer to normal wiki behavior. And I expact that to be important for wiki users converting to AgileWiki.

As for the display of table lsecs in the swing client, I believe conversion to HTML can reasonably wait until after AgileWiki enters beta. This then leaves 3 areas of development needed before AgileWiki enters beta:

1. Implementation of brace notation.

2. Reference and ciatation processing.

3. Database utilities.

I'll also note that the database is now quite solid--it is no longer breaking during normal development, which includes running multiple copies of the server and repeated hard-takedowns. Of course, that's what you expect from a transactional system.

Bill

Wednesday, June 07, 2006

an easy morning, but still some good progress

Yesterday I got up at 3:30AM to work on AW, and then put in a full day at work. Needless to say, I was a bit tired and went to bed early. So I got up late this morning--5AM. :-)

The main database file has had a file lock on it for some time now. It prevents two servers from running at once. But still, I have been experiencing crashes when one server is stopped and the other starts running.

This morning I tried putting a file lock on the before image file. That shouldn't make a difference--the other file is always opened first. But I don't seem to be having the problem I was before. So I think I may have fixed a problem--time will tell.

Two other things I did this morning. First, I changed the scope of the crCabinet command. An AdMin can now create a cabinet from any role. I.E. Not from a JSec. And, of course, Cabinets are always children of the Ark.

Next, I added a new command, crDrawer. Again, the scope of this command is role. And Drawers are always created under the current Cabinet or the Ark.

Now once I've added crFolder and crPage, I can drop the crTopic command. And then we've solved the child/peer issue.

Bill

Tuesday, June 06, 2006

various issues

Before starting the backup utilities, its best to review any outstanding issues.

1. Tables

In the Swing client, tables can not display links. OK, what happens if you reference a topic? I think it should be a valid reference, and clickable.

So tables should be displayed using HTML.

2. Citations

Citations are inverted references. I want to work on them only after dealing with the above tables issue, but as they involve an inverted index they should be delt with before doing the database utilities.

Citations are needed for completness--they are an important part of a Wiki and should be completed before we say "its beta now".

3. Curly Brace Notation

As not all topic names need be proper wiki names, we need a way to identify references to topics within text when dealing with such a non-standard name. So we put {curly braces} around it. And double curly braces when a proper wiki name is NOT the name of a topic. And \{ and \} notation when the curly braces are simply curly braces.

4. Topic Creation

Lots of considerations here. Do we want to allow a Page to be created in the Ark directly? In a Cabinet? Or only in a Folder? Well, with a moderately deep structure (Ark/Cabinet/Drawer/Folder/Page), we probably don't want to force really deep structures. On the other hand, since documents can be held by topics at all levels, is there any advantage to having anything but Drawers in a Cabinet? Perhaps not, especially if we can move a Drawer, putting it inside another Drawer, and have it automaticly become a Folder.

Another big issue is child vs peer creation. In a directory structure, a create always creates a child. But in a wiki, a create topic always creates another topic (at the same level). But I don't think having createChild and createPeer is the right answer. Instead, lets have createFolder/createPage etc.. So if you are "in" a page and create another page, a peer is created. But if you are in a folder and create a page, it creates a child. Now if you are in a page and create a folder, then it should create a new folder in the same drawer. But if you are in a drawer, you can not create a page (not applicable).

OK then. These are the 4 issues I'd like to resolve before doing the database utilities. Completing them will (in one case) help stabalize the data structures, but mostly bring us ever so much closer to being done with alpha.

Bill

release alpha 26 will be coming soon, back button

The back button is now working on the swing client. It really does help make things easer to use.

So I figure its time to do a release, and then maybe I can start working on the database utilities. Perhaps tomorrow morning?

This next release (alpha26) will include enhancements to the rolonic view (swing and web clients), the back/forward buttons (swing client) and the fix to the restart bug.

Bill

Monday, June 05, 2006

bug fixes

Fixed the bug today which causes the server to reinitialize (and sometimes crash) each time it is started. Also, the swing client has been crashing when run its version does not match the server--it now exits a bit more gracefully.

Finally, I've decided to add a back button to the swing client before starting the database utilities. That should make the swing client a lot more friendly.

Things are progressing, if a bit more slowly than before--I've been programming for my day job, too.

Bill

Sunday, June 04, 2006

finished with the GUI for now

The new wiki interface was included in release alpha-25. But I found that disliked having the document content, Ledger Sections and Children displayed one after another on the web page--it is too easy to miss the presense of a ledger section.

I've since added tabs to the web pages in the form of a simple header bar in the IFRAME. This header bar indicates the elements present as well as a means of displaying the selected element. And this enhanced display is for both wiki and rolonic views.

Finally, I moved the classifier entries in the rolonic view out of the header, on both web pages and the Swing display. And I think that's it for now. There are more pressing items calling for my attention.

There are then 2 major areas which need to be worked on asap: commands and database utilities. We can probably manage for a while with the existing command set, but the lack of database utilities keeps AW3 in alpha and prevents it from being self hosting. (Why invest the effort in content when you can't back it up?)

So I will be focusing on the database utilities now. Hopefully I can complete them this month.

Things are going well.

Bill

Friday, June 02, 2006

stats, wiki interface

May was our second best month for downloads with a total of 108 downloads, 81 for AgileWiki3 and 27 for AgileWiki2. Which isn't all bad for an early alpha and a discontinued beta. :-)

It also looks like this weekend we will have a very nice release, with the first draft of the new Wiki interface implemented now for both the web server and the swing client. (The Wiki interface will now be the default view.)

I'm inclined at this point to stay focused on the GUI for a while longer. First I want to clean up the original interface, which can still be accessed using the rolonic command. This is a more comprehensive view that enables advanced features like access control.

After that there are a number of further improvements that can be made in both views. So figure another week or two before I finally start work on the dump/restore utilities.

I expect then for AgileWiki3 to become self-hosting some time in early July. Soon after that we will declare that AgileWiki3 has reached beta.

Bill

Thursday, June 01, 2006

simplicity does not come easy

I've now finished the wiki user interface for the AwSwingClient and it is checked in on java.net. Now I've got to work on the servlet.

I've made every effort to make the wiki as simple as possible while still providing a reasonable amount of utility. It really has come a long way, though the command set is still weak.

Bill