on a privacy rampage today

I've been doing a fair amount of testing of privacy today, and I've now blocked all the known holes.

We needed privacy in AgileWiki2, but I refused to do it, as the code base was too well developed and there whould have been too many holes requiring rearchitecting. That's why privacy has been included from the beginning in AgileWiki3.

Its looking good. Oh, and I got that up command working. Quiting now for the day--going to the mall. But there's always tomorrow.

Bill

great progress on AwSwing wiki

I started working in ernest today on the swing client's wiki interface. Still a few holes (I need up, children and lsecs commands), but it is really looking great.

Meanwhile, I've got the mailing list blues. Last weekend the sourceforge mailing list server was acting up, so I switched everyone over to the java.net mailing list server. This weekend the java.net mailing list server looks like its down. Guess I should just maintain both lists, but then what about the archives?

Bill

a turning point

I've spent the last few weeks cleaning up the internals of Aw3. There are two major items left to do to complete the alpha:

1. The GUI needs work. No suprise, I've been complaining about it for quite some time. But I've also been working on the server-side support for these changes. Progress has been made.

2. The dump/restore utilities are needed. First, the internal data structures needed to be stabalized. This has now been done.

Release alpha24 had a lot of small changes, like giving each user a cabinet, the creation of session lsecs and a small but significant change to the GUI (an OK button now found on several displays). But the good news is that the groundwork has been done. The alpha is nearing its end.

Finally!

Bill

session rolons without persistant data

This could be called a cheat. Or perhaps the 80/20 rule. Anyway, having created SessionRolons, which are distinct from session objects, I realized that you do not really need persistant session data. Its enough to have the session objects to hang the transactions on. :-)

So I've finished it. SessionRolons are created in the current day of the Ark. Session update transactions, login and register all then are added to the session rolon's journal. As well, they are added to the journal of the current day of the cabinet of the current context--but using the current contex after the command executes.

So now I am free! Oops--I mean, its back to the GUI.

Bill

working on architecture again

I've again dropped the GUI work in favor of a substantial change to the architecture--persistant sessions.

Sessions will be LSecs under the current day in the Ark. The trick is that there are no locks in place and no transactional context at the time you create a session, so the create must provide for it all. Also, the current day may not yet exist, so again you are creating things and must do the write lock and establish the transactional context.

Of course, having a Session rolon (for persistance) means that all the evaluators/forms must also be converted to rolons. Sigh.

This is all new--AgileWiki2 was simply not fast enough to do this, much as we wanted to at the time.

Bill

Calendar and Journal

Priyanka has been working on the weekly calendaring system for each cabinet. I'm happy to report that it is now working, though currently we are only creating days as we use them. (A sparse calendar?)

Journal sections are now also attached to the current day of the cabinet. So you can go the a day, do a jnl command and view all the activity for that calendar for that day.

Bill

The 3 phases of AgileWiki3's development

As Aw3 is a reimplementation of Aw2, there is no rush to implement the more interesting rolonic features. Rather, the interest is in a phased implementation where each part is given proper attention and implemented completely.

The first phase was the implementation of the underlying database, with full rolonic capability, and to implement most of the framework and a workable GUI. I call this the Ugly Dukling phase, as there are interesting but unexpressed capabilities, but the overall system was obviously quite incomplete and could not be used to accomplish anything. This phase is complete except for the lack of the dump/restore capabilities wich require a bit more stability than has yet been achieved.

We are now in the second phase of development. In this phase the emphasis is on doing a few simple things well. Quality and utility are important. Aw3 becomes a usable Wiki. Things become less awkward but the more interesting capabilities of the underlying database (time navigation, posting, rollbacks, streaming content and classifiers in general) remain undeveloped. Aw3 becomes a YAW (Yet Another Wiki). My sincerest hope is that we will be done with this phase in another month or two at the most. But it is a good time to learn the basic architecture. And small things of interest here and there will crop up, though they may simply apear to be quirks. In this phase it looks like there is far too much architecture for such a simple thing as a Wiki.

Then finally in phase 3 we realize the potential of the underlying database and framework. Finally that ugly duckling becomes a swan. All those odd parts pull together into something new and wonderful.

Its all been prototyped in Python. In the last 6 years, Norm and I have explored a lot of interesting capabilities. But there were speed limitations which kept us from completing it. And being prototypes, the focus was not on architecture, but on exploring various capabilities.

The architecture of Aw3, in contrast, is quite sound. And we have achieved the speed we need to do things like having a persistant session, where even context changes are saved in the session journal. Our goal then is to build our first production system, integrating all the capabilities we previously explored. And to build a community of developers who have some understanding of the theory it is based on and how to us it to build richer and more natural systems than are possible following conventional software engineering practices.

Bill

A game for the Wiki

Sougata has just contributed a small application--the guessNumber game. It doesn't use persistance or anything. But what I like about it is that it is the kind of thing you will not find in most Wikis. It makes a point--this is an application platform.

This will be included in the next release. :-)

Bill

alpha23 is alive and well

Catch the new release at http://agilewiki.org/AwServlet/index.html

Note that you can also access same using the AwSwingClient, but you will need release alpha23 to do that: http://sourceforge.net/project/showfiles.php?group_id=106672&package_id=179488

This release includes the ability to create/destroy/change topics, as well as support for wiki links. So things are coming along.

We've also started putting a team together, but only just: http://agilewiki.org/AwServlet/team.html

Bill

things are moving right along

Wiki links intermixed with HTML works great.

I've also added a crt command for creating topics.

Next up is going to be destroy, giving us then a minimum set of maintenance commands.

Next week the emphasis should shift to developing our first application, content management. For that we'll need a new, very simple user interface model which just displays the HTML content. End users then can just view the content, navigating with only the links embeded in that content (including wiki links), while content managers can use the original user interface model for managing the content.

Of course, the whole problem with this is that, without the dump/restore utilities persistance of content is a bit iffy. But at least we'll have something to show. And we're still early alpha.

Bill

WikiLinks

With so many areas of AgileWiki3 left incomplete, what is the one thing which would enable the most capability, which is only dependent on things that are already working? This is a question I often ask myself. Of course, the answer changes as the implementation progresses.

Right now I'm thinking that the thing that would be most useful would be the recognition of WikiNames in content and their conversion to a web link in the display. This implements the combination of HTML editing and WikiLinks, which should be quite a powerful combination for users.

Bill

AgileWiki3, Live!

Well, its a new milestone. Nutari (our ISP) is now running AwServlet in TomCat. The link to it is http://agilewiki.org/AwServlet/index.html

There you will find both a link to the server itself and our team page.

Note however that we are still in early alpha, so there's no content. And any content that you add will be gone in the next release. :-(

Bill

In transition, an interesting time

The development effort for AgileWiki3 is very much in transition. I've been the only developer on a succession of projects these last 6 years, and now there are several developers aiming to contribute their best and learn a lot in the process. And they are not all newbies.

I do not see AgileWiki successful with only one developer. So the only downside to spending time helping other developers come up to speed is perhaps a slower pace of development in the short term. But they bring with them a possibility of a larger success.

If you look at the updated project home page, you will now see a greater emphasis on how to get involved in the project: https://agilewiki.dev.java.net/

Bill

changing the past?

Currently AgileWiki supports only changes made in present time. Changes made to Journal Sections (transactions) really only effect the view of a transaction.

When a change is made, change entries are added to the database for each property that was changed, and the time of the change--which serves as a link to the Journal Section describing the transaction. But Journal Sections (JSecs) are themselves first-class user objects that can be changed. Perhaps we should limit then what can be changed in a JSec. Without question a NPJS (a Non-Performing Journal Section) can and should be changable, if only by its author.

Of more interest would be if we wanted to remove the (past) impact of a transaction, or change the time of its impact. These would be changes in past time, and could have strange consequences. If we want to model organic systems, this is an important capability. Something to be addressed in AgileWiki4?

Bill

headlines

This morning I worked on headlines. Now every topic can have a headline and the headline command can be used to create them.

Headlines (or names, when there is no headline given) are now also used as the web page title. This is helps with indexing--which is important if you want folk to be able to find your content.

We've also taken a step closer to having AgileWiki3 web pages accessible at agilewiki.org. But right now it only works through vpn. :-(

And I think its about time for a release, before work starts on integrating a Cabinet's consolidated jorunal with a simplified calendaring system.

Bill

ch, private

Two more commands have been implemented in AgileWiki3:

ch - change the document content of a topic; and
private - restrict read access to a user or group.

Now ch is just an AgileWiki2 command carried forward... almost. We do support both plain text or html, so that's a change.

But private is something that was not in AgileWiki2. It allows us to have private cabinets that can only be accessed by a select group. It also means that users can have private topics in their home cabinets that only their close friends can access.

There's problems of course, especially with group definitions. This is where a simple delegation trust model is helpful. But not right now, hmm?

Bill

Using AwSwingClient with a web proxy

java -Dhttp.proxyHost=webcache.singapore.sun.com -Dhttp.proxyPort=8080 -jar AwSwingClient.jar &

I'm using the above command command to run AwSwingClient from work. This is one of the nice features of using RMI. You only need to set the system properties http.proxyHost and http.proxyPort to point to you company's web proxy. It does what is called http tunneling, which is a little slower than using straight RMI protocol, but hey--it works!

Bill

revised help facility in release alpha21

Well, I didn't get to everything in that todo list I made for this weekend, but I did include a few extras, like making help more accessible and making the commands listed by help "clickable" as a convenient way to execute commands.

There's now a handful of folk who've joined the discussion list and expressed interest in working on AgileWiki. But its a long way, especially on a project like this, from an expression of interest to active participation. But I'll do what I can to help.

Bill

done with forms for the moment

Forms now support checkboxes and the npjs command now sports one--your input document is now treated as either plain text or html, depending.

What's next? A whole bunch of things are calling my attention:

• A back button for the Swing browser;
• Adding headlines to all rolons, updating the display and updating the crc to take advantage of it, as well as having AwServlet use the headline as the web page title (for indexing purposes);
• Implementing the ch command so we can add content to more than just NonPerformingJournalSections;
• Adding version checking to AwSwingClient, least we get strange bugs when running across versions; and (done)
• Updating the redirect at http://compstrm.sourceforge.net to point to http://agilewiki.dev.java.net; (done)
• Replacing the .jsp file in AwServlet's war file with a plain .html file; and (done)
• testing some ideas I've shared on the developers list about how to handle image files. (done)
• And, oh yes, writing bash scripts to start the rmiregistry and AwServer. (done)
• And then the welcome message for register and login should be changed to html. (done)
• Did I mention revalidating scripts and the text client against the new additions to forms? (done)

Phew! Looks like a busy weekend ahead. :-) Unfortunately I'm a bit Fridayed--need to catch up on my sleep more than anything. :-(

bill

Make it real simple when you can

Lots of emails lately on the compstrm-wiki list. James has joined the project and has started to contribute. He's a graphics artist who wants to learn java. He's picking up NetBeans and has been busy installing subversion on his Linux system. And it looks like we're going to have lots of fun working together.

I now have html content displaying in forms. And there is now a Cancel button on forms as well. Next will be checkboxes.

But I was struck by a thought today. Since rolons can now hold web pages (as html), why not just display that content unless a user has logged in. This gives us full control over what a web surfer sees. Its just HTML content with resolved wiki words. Only when you login do you see that its a wiki. And only if you select an advanced user interface model do you get to see all the advanced stuff for configuring applications.

Feels right.

Bill

Image content

When I was at the FOSS conference in Banglore, back in October, I was advised to add images. Good advice, especially as documents are displayed as HTML.

So I am thinking, a rolon can have an image as its document content, with classifiers giving its height and width. then when WikiWords in a document are transformed for display into HTML, if a WikiWord names a rolon with image content, the WikiWord is replaced with the HTML for displaying that image. There's only one complication...

The AwSwing client will need to implement a protocol handler for accessing images downloaded from the AwServer. I've done things like this before, but never for images.

There's also a complication with AwServlet. Servlets don't normally serve up images.

I think this will come later, unless someone else wants to work on it.

Bill

one nice thing about windows

In the directory of the AwSwingClient download directory, I did a right-click drag on the jar file and created a shortcut on my desktop.

Now just a double-click on the shortcut icon and bingo! The AwSwing program is running and connected to the backend on AgileWiki.org. :-)

Of course, this all will be much nicer when AgileWiki3 is actually usable. Perhaps in a few months? :-(

Bill

running on agilewiki.org

I've now got AwServer running at agilewiki.org. Unfortunately, Jakarta isn't running there yet. But in release alpha20, I've included the AwSwingClient jar files as a separate downloadable file--and its only 90KB, though it does require J2SE to run. See
http://sourceforge.net/project/showfiles.php?group_id=106672&package_id=179488

Hopefully now I can get back to working on forms.

Bill

RMI and firewalls

Much of my available time has gone into getting RMI working behind a firewall. Learned all about java.rmi.server.useLocalHostname and rmi.server.hostname system properties, as RMI kept insisting on using the wrong IP address for the server. Finally I used rmi.server.hostname to set the explicit IP address and then nothing worked.

Anonymous ports were blocked.

So now I'm providing for seting the server port explicity in an optional property in the (optional) property file--the serverPort property. It will default to 0 (anonymous port).

I'm probably going to just go ahead and do a release. That's much better than having a unversioned set of code sitting out at agilewiki.org. Hopefully soon you will be able to point the swing client to agilewiki.org and access AwServer. Not that it will do much.

Anyway, this AM I updated AwSwing to support clicks in web documents. Its now a mini-browser, though lots of things are not supported as it is based on JEditorPane.

Bill

IFRAME and JEditorPane

I've now added a second servlet to suport the use of IFRAME. Works great--you can now have a web page as the content of a rolon.

I'm also using JEditorPane in AwSwing to display same. But I'm thinking I need to enable links. Then the two clients will work similarly.

I've yet to really get started on adding additional text to forms. I got sidetracked because that text should also be html, sans the IFRAME but still using JEditorPane to display the text in the Swing program.

And I still want to add a checkbox to the npjs form to allow the use of either plain text or html. (And the npjs logic will serve as the prototype for adding content to all rolons, which is why I'm putting so much emphasis on it.)

Bill

running AwServer remotely

My ISP has set up an account for me on another machine and I was able to install AwServer. And there was no problem with AwSwing on my laptop accessing this remote server. A pause of a couple seconds (India to Canada and back!) was all that I noticed. But I was doing this via a vpn. For the moment, port 1099 can not be accessed from the internet. But I'm sure something will be worked out in a day or so.

The plan is also to run Jakarta on this new system, so content can also be accessed from a browser. So my main problem remains--too much programming left to be done.

Bill

The MimeType Descriptor Entry

I'm now tracking the mime type for each rolon as a descriptor entry. Conversion to HTML, as required, is done at the time of display by AwServer.

Currently when entering an NPJS document it is assumed that you are entering HTML. But it seems reasonable to give the user the option of text/html or text/plain. :-)

Now it is probably also a good idea for AwServlet to wrap the document in an IFRAME. This then would allow the use of any HTML document, within limits--not everything is supported by the JEditorPane used by AwSwing to display HTML.

Bill