Sunday, April 30, 2006

when it is too simple, there are endless complications

I've so far managed with only one type of document--and considering how little functionality has been implemented to date, that's really not suprising!

Now I'm treating the document attached to a rolon as HTML. Ooops! Request events are stored in the document of a JSec. OK, so I convert that to HTML. But I'm uncomfortable with this, as it reduces the utility of the data. I'd rather store request events as text/plain and then convert to text/html on display. Easy enough to whip up a content descriptor entry. But when should the conversion be done? Hmm. I could even store the request event as text/xml.

I think the best, and most obvious place, to do the conversion is in the client. We just need to carry the content type.

Bill

There is a problem with Wiki markup...

There is a problem with Wiki markup. Which Wiki markup? Exactly my point!

And what about casual users? Wiki markup was intended to be something easy to learn. Why not leverage HTML? Why not allow both? For example, n linefeeds could become n-1 <br>'s (at the time of the display). Well, OK, that would be bad if you paste in a regular HTML doc. But still we could expand WikiWords.

So if we support HTML with only WikiWord expansion, I think we have a nice comprimise. HTML for formatting, and expanded WikiWords for ease of referencing other documents in the Wiki.

Now I've been working on the display of the NPJS document. It now supports HTML when using either AwSwing or AwServlet. Also, when a link has a href that starts with "AwServlet?cmd=", then clicking on that link executes the subsequent command... in BOTH AwSwing and AwServlet. (All other links being ignored by AwSwing.)

Bill

Proof of Concept

Release alpha-19 demonstrates the use of a very light-weight XML document, specific to a User Interface Model, to decouple applications from clients.

These are not true thin-clients, but rather implement a limited set of User Interface Models, built from a number of elements like Doc, EditDoc, EditText, Password, etc. Clients then are easy to program/maintain. And the documents exchanged with the server are quite small.

OK, that's nice. But what's usable? The database lacks a dump/restore capability. Even simple commands for creating content are missing. The UI model is a poor one. And the clients are a bit on the crude side.

Well, what we have, finally, is an application framework that supports a range of clients, built on a database that supports time navigation, nested transactions and scripting.

Next steps? I want to add some descriptive text to the various forms. And I want to add headlines to all Rolons, not just JSecs. Then work on some additional commands, like create, destroy and rename.

In AgileWiki2 the title tag was used to create the HTML title--which is important for indexing services like Google. But I think this is best served using a headline. Headlines will also add to the value of a topics listing, methinks.

Bill

Saturday, April 29, 2006

Login and register now work from a web page

Good progress today with AwServlet now handling login and register. And that meant a lot of JavaScript in the web pages for secure hash and challenge/response. (I'm uncomfortable working with JavaScript--diagnostics are a bit short.)

Is kinda cool. You can create an account using Swing on your home computer and then login from anywhere using a browser. Of course, once Arks are networked it means you can access your home system via a public Ark even if your home system is not publicly accessible. Hm. We definately are going to need private arks where you must first login before anything else.

I need to validate all the forms now. I figure a release tomorrow morning (late Saturday evening US time) is likely.

Bill

Friday, April 28, 2006

this and that

I've now fixed cursor positioning in AwServlet to handle forms. I've also renamed this project from AgileWiki3 to AwServlet. You will also notice (on svn) that I've added a README.txt file for AwServlet. Guess I'm getting ready for the next release. :-)

There is an applicability error in the commands I've just converted to forms--they don't check to see if the user is Guest. Gotta fix that, though I've been using that bug for the initial work on AwServlet's forms processing. And the next biggie is user registration--lots of JavaScript needed to encode the passwords.

Tonights going to be a bit crazy, what with Rupali arriving in Bangalore at 3AM. But its a 3-day weekend (no work Monday), so I may just be able to finish form processing and release it. And that finally puts the infrastructure to bed for a while.

Meanwhile I've been thinking about how multiple Arks (the backends) can network. All I really need to do is have a proxy exchange method in PortalInterface. But. Each Ark would need a unique name. And there needs to be a list of the publicly accessible Arks with which proxies should be exchanged. And at a minimum, a user should be given the option of interacting directly (via the client) with any known Ark currently on-line. Call it a network of resources. Of course, it only gets interesting when there are Cabinet proxies so wiki pages can reference pages in other Arks. :-) But when will I get to this? :-(

Bill

reconfiguring the embeded tomcat

I just got AgileWiki3 running on Solaris 10 using the tomcat server embeded in NetBeans. But in this configuration, tomcat runs using j2se 1.4 and my RMI fails. But fortunately it is easily reconfigured. From the runtime window, open servers and right click on tomcat. then select properties. From there you can change the java platform to 1.5--that is, if you've set up NetBeans to use j2se 1.5!

Bill

Thursday, April 27, 2006

p2p

OK, I'm a bit slow. I just realized that by using RMI it is easy to get Arks communicating peer-to-peer. This will be great when sharing content or for IM when two users are logged onto different arks. It also makes it easy to replicate user registration across a network of arks.

Now I'm thinking that most arks will not have a public IP address. These arks would need to connect to a publicly accessible ark to join the network. Could be quite interesting. Unfortunately, there's miles to go before I have time for this.

Developers welcome!

Bill

the good and the bad

I'm now blocking the use of forms in combination with the brower back key. And I've just added some simple error handling to AwServlet. I've also layed the groundwork for forms processing. Hopefully forms will be done this weekend.

Meanwhile, I've just figured out that the link on agilewiki.org to the introduction is broken. I'll fix it tomorrow--when I'm a bit fresher. :-(

Bill

Thin Clients that are easy to program

Thin clients aren't usually easy to program. The difference here is that AwSwing and AwServlet are aware of the UI model(s). So these are not generic thin clients, and that's a great simplifier.

Progress on AwServlet has been rapid. Done in fact, except for forms--which is to say I'm about half done, considering the amount of JavaScript needed for login and register. (Though I expect to crib a lot of that from AgileWiki2.)

One thing I am NOT worrying about right now is the use of the back button on the browser. Handling that properly is a big complicating factor.

Now a bit of good news. It looks like my ISP is willing to host Jakarta. So before May is out you'll be able to access AgileWiki3 web pages and perhaps even download AwSwing via web start for use as a remote client.

Bill

Wednesday, April 26, 2006

AgileWiki.org has been restored

I've had to restore an eariler version of the AgileWiki database at agilewiki.org. But at least its back up. And I've updated the intentions page.

Bill

progress but

The AwServlet is going nicely. In addition to click-navigation, I can now enter commands. What remains are error handling, help displays and forms. (But the t command works nicely.)

Meanwhile, after running for so long the AgileWiki.org site is down. On restart it just dies a silent death again. I'll look into this tonight. Ah vie.

Bill

Tuesday, April 25, 2006

A good begining on AwServlet

I'm delighted to say that you can now click-navigate around the ark from a web page. Still a lot left to do, but this is a very fine start. :-)

Bill

Sunday, April 23, 2006

NetBeans and Servlets--a Joy!

I've now been able to create a simple servlet which interacts AwServer. The only complication was having create a J2EE1.4 version of the AwCommon code.

NetBeans with its embeded web services is a Joy to work with!

Bill

time out

Its been quite a while since I took a break. The work is done, the release is out and I'm taking some time off and reading a book. I'm still thinking servlets is next, so this is a nice break point.

Be well!

Bill

Saturday, April 22, 2006

Creating new forms is a snap!

I've just converted the restrict, npjsRestrict and crc commands to forms, and all 3 support a headline. And I'm delighted to say it was quick and easy to do... And there were NO changes on the client side. :-)

One big project that is pending is the AwServlet, and I'll likely do a release before that. But there are still two things remaining:
  1. Currently to add a command, you need to modify the class of the Rolon it is associated with. I'd rather have command know which Rolon it is associated with and add itself to the Rolon's list of commands when the command is created. I'd also like to have a file which maps command names to Java classes, just like the file which maps Rolon names to Java classes.
  2. I'd like to rework the Validate class, breaking it into a collection of classes and have a similar file mapping from field type to Java class.

I'm thinking that these changes will add considerably to the extensibility of AgileWiki3, which is vital for an application server.

Bill

more cleanup

Ledger and Descriptor Entries are now displayed, along with tables. My thoughts now are turning to Journal Sections.

Non-performing JSecs support a headling. I'm thinking this should be extended to all JSecs. This will allow a user to add a comment when updating the Ark. Then when commands like restrict are converted to forms, it will be an easy matter to add a headline field.

I've also (finally) writen the 1-liner .bat files for running the rmiregistry, the AwServer and the AwSwingClients. I've put these in the top-level directory where they're easily accessible.

Bill

Friday, April 21, 2006

What's the point, where's the payoff?

I have put considerable effort into the AgileWiki and will continue to do so. Why?

Because an implementation of a Rolon is a generic first-class user object. The catch is that you will learn to think in terms of ledger, journal, classifier and descriptor. But having framed an application object in those terms, your data and inter-object relations are already implemented for you. You just add the "business logic".

That's pretty powerful. It is heads and sholders above EJB or anything else. That's why.

So why hasn't it been done before? What's wrong with EJBs and Portlets and all the rest?

First, Rolonics separates out classifiers, which define the inter-relationships. A comprehensive set of classifiers can be implemented by the container (the Ark). You just plug your application into that and turn it on, and you've just finished a big part of your application. This is a very different (and much more general) approach than is taken by any other application server.

Second is time. Most application servers break when you add some aspect of time--it is always implemented with the ledger (state), and time as structure never works except as a special case for limited problem domains. In contrast, a Rolonic system includes time as a major aspect of the overall implementation. Applications which deal with time present no difficulties to a Rolonic Application Server, like the AgileWiki.

'Nuff said!

Bill

AgileWiki.properties file

Well, I cleaned up exception handling in Portal, broke out a separate Main class, changed Session into a Cachable and added an optional property file.

There are 15 properties that can optionally be used to tune and configure AwServer. One of particular note is rmiName, which allows multiple servers to be run on the same machine.

Clients now also take an optional property file for specifying the rmiName. This is necessary when the client and server are running on different computers.

General value add, mm?

I've also been thinking about private arks. These could be set up with their own server. All I really need to do is add another property which forces you to login before doing anything else. (So a valid user would need to register for you.) Sounds like this would also require email validation of users and the ability to change passwords. It can wait for now.

Bill

trip cancled

The wedding is delayed due to an injury from a receint accident the bride was in.

Bill

Thursday, April 20, 2006

off-line for a week

Early tomorrow morning I fly from Bangalore to Delhi. The connecting flight from there to Jaipur has been canceled, so I'll be taking a bus from Delhi. :-( I'm no tourist, that's for sure. And I'm always skidish about traveling alone in India.

Wish me luck!

Bill

Plans for the week

Anil (my brother-inlaw) is getting married! Tomorrow I fly to Jaipur for the wedding in the bride's home town, then continue on to Raipur by train for the reception in Anil's home town, as is traditional.

Of course, my laptop goes with me and I expect to have some free time during this. My intent then is to focus on cleanup and enhancements. I'd like to eliminate the prompt event, as it is now unchanging and therefore redundent. I'd like to convert all commands except queries to use forms--like the restrict command. Add a headline to Journal Sections which can be entered from the form which requests an update to the database. And convert the help display into menus, as well as making the Swing interface fully keyboard navigatable. Then eliminate the command entry. No, I don't expect to have time for all of this, but I can make a good start. :-)

I've also been thinking that there should be another layer between Ark and Cabinets--companies. Each company would have its own users, and there would be NO interconnections. A company, and even its presense, would be invisible until you login to that company. (The login form then would have an additional field--company. But this is likely not for this coming week.

Bill

Wednesday, April 19, 2006

intentions

Time I started laying out the intentions for implementation of AgileWiki3.
  1. A bit of cleanup on the top-level framework. Sessions in particular should have some kind of timeout mechanism. Otherwise we've got a memory leak, as restarting the client simply opens a new session.
  2. The AwServer and clients should continue to work "out of the box", but we also need to be able to configure the RMI. A different port may be needed. And when running the client on a different machine, you need to specify the host. I'm thinking an optional property file might be good here.
  3. We need a servlet to drive the web interface. (No, not SOAP. Not for a while!) I'm thinking this should be a priority, least we design ourselves into a corner with Swing, otherwise I'd put it off.
  4. CEnts are being displayed, but how about LEnts and DEnts? Need to verify this or fix it.
  5. We need to be able to change all the necessary CEnts/LEnts/Dents. Some are done. Easy stuff, with a slight complication for access control. We also need to be able to edit documents and tables, as well as create Rolons.
  6. Privacy needs to be implemented early, restricting the ability to view content. Two use cases here: (1) restricting visibility of a cabinet to a user group and (2) restricting visibility of personal content to the user, e.g. user email address. We don't do it early and it gets very diffilcult.
  7. Support for navigation by pathname.
  8. We need to support WikiWords in documents, and citations.
  9. Real live classifiers: include, export, tagmatch, importmatch, importtag, export.
  10. rename/refactor
  11. move/refactor
  12. restore
  13. post
  14. destroy
  15. promote/demote
  16. dump/snap/restore
  17. calendar
  18. A guestUI.
  19. A rolonicUI.
  20. Row entry form for tables.
  21. Table descriptor creation wizard.
  22. Deligation of privileges.
  23. sharing between arks
  24. cabinet proxies
There's more, I'm sure. This is just off the top of my head. But even this will keep me busy for quite a while. Anyone want to join the fun?

Bill

An addendum--Tables

In the AgileWiki, tables are implemented as a kind of document. A rolon with a table document has a descriptor unit which defines the various columns and the means of validation of the content for each cell and row.

Several tables are used to define the behavior of the wiki itself. Table descriptor units have a table defining the columns of a table and the validation rules. There is also a group table which assigns users to various groups for different parts of the ark. This is used for acces control.

Rolonics 104--introducing namespaces

Every rolon has a UUID. Its a 128-bit hexidecimal string used to uniquely identify it. UUIDs are generated using a secure random number generator, so there is a pretty good asurance that each UUID is unique. UUIDs are used in defining structures, so a list of the children of a rolon is simply a list of UUIDs. They have other uses as well, inverted classifier name/value pairs being just one.

However most referencing made by a rolon to other rolons is done by name. The AgileWiki borrows heavily from programming practice here. Structures of rolons provide the basic namespace, as a child inherits the namespace of its parents. Additionally, each rolon has a list of classifier rolons used to augment this namespace. (This list is refered to as the applicitive context.) These two mechanisms intertwine then, as a child rolon also inherits the namespace derived from the applicative context of its parents. And there are five kinds of classifier rolons which can be found in a rolon's applicative context.

1. Include Classifers: The name of another rolon and its children (and exports) are added to the namespace.

2. TagMatch Classifiers: Rolons may be tagged. These are inverted name/value pair classifiers. A TagMatch classifier gives a tag name and a value regex. Any rolon with a matching tag then is added to the namespace.

3. ImportMatch Classifiers: This operates the same way a TagMatch Classifier does, except that it matches against ImportTag classifiers rather than inverted name/value pair classifiers.

4. ImportTag Classifiers: The entire namespace of any rolons with an ImportMatch Classifier which matches an ImportTag Classifier is includeded in namespace.

5. Export Classifier: This classifier has a name and a pathname in its ledger. The pathname is used to define a new name that is added to the namespace.

Wild stuff. But of what use? The AgileWiki supports a multiplicity of namespaces, just like any large programming project. This works out a lot better than having long global names. Its a lot more manageable.

One item of note, ImportTags. These are a means of providing "instant" namespace to streams of rolons entering the wiki. Add a few import tags to an email or blog post and it gets plugged into an extensive context for resolving any wiki names that are used.

The AgileWiki then provides an extensive ontological framework for defining namespaces and resolving names. We believe that this solves the problem that killed early work in Artificial Intelligence, and that the AgileWiki may serve as the basis for its resumption. But likely not AgileWiki3--there's a lot more coming in the future that will NOT be included in this version!

(Did I tell you that my friend Norm is a consulting ontologist?)

Rolonics 102--a brief introduction to the AgileWiki

The AgileWiki is a Rolonic based system. And there are only 3 types of data: documents, name/value pairs and Rolons. You could say that it almost turtles all the way down.

Every rolon has an optional document associated with it, a WikiPage, a web page, a word document or whatever. Descriptors on the rolon identify the mime type.

Then there are the name/value pairs. Some of the simpler classifiers and descriptors are implemented as name/value pairs.

Finally there are rolons. A rolon's journal is a series of other rolons. Its ledger is a structure of rolons. And the classifiers are ledgers as well. Finally, every rolon has a descriptor unit which is of course another rolon. (Yes, there is one generic descriptor unit of descriptor units rolon which has itself as its own descriptor unit. But there are other more specific descriptor units for specialized descriptor units too, as well as a host of rolons which serve as descriptor units for non-descriptor unit rolons.)

But rolons change over time. And the AgileWiki supports queries for changes over time and the state of rolons for any past time. This is where the database comes in. Name/value pairs, documents and rolons are not stored in the database per say. Rather, their changes over time are recorded. So for example, the value of a name is determined by starting at a given time and proceeding backwards to find the first (latest) applicable assignment.

Now in addition to these data structures, there is also command logic. Each command is implemented a thread-safe object with several methods. Commands are then associated with various types of rolons, which defines their scope. Each command has a help method, which gives a brief description, a process method to perform the defined operation and an applicability method. This last method is the command's classifier--it determines the conditions under which it is valid.

The AgileWiki then is comprised of a simple set of data structures, a form of versioning and semi-smart commands. Reminds me of lisp a bit. But its very simplicity allows for very effective caching logic, making it all very fast. And it is easily built up into complex structures able to describe most any application. But there is also a bit more. I haven't said much about relations between rolons (classifiers).

The database supports lists, which are ordered sets of rolons. Lists are used to implement structures. So a rolon can be the parent of a list of child rolons. And a rolon can have a list of parent rolons. (Think non-cyclic graph.) Further, the classifier rolons of a rolon are also a list defining the applicative context for that rolon. You can order the list, and that defines preferences when determining a rolon's context.

Further, some classifiers which are name/value pairs are inverted in the database, as these classifiers are used to quickly locate rolons of interest.

Tuesday, April 18, 2006

The Rolonic World View

There was a time when we thought of everything as objects. The emphasis was on thingness, and the colocation of data and methods. But learning how to program with objects took some doing. That was back in the early '80s. Then Microsoft brought us the Common Object Model and Sun Microsystems gave us JavaBeans. Now we have components, factories and better decoupling. And then nothing, except for a lot of ad hoc systems with short-term goals, like Portlets and SOA. EJBs have taken a back seat to POJA, and AJAX is the latest fad. Software has become driven by fashion.

Now I often talk about Rolonic Theory, and AgileWiki uses terms like classifiers, descriptors, journals and ledgers. Time again for a quick review of the basics of Rolonics.

Fundamental systems with tremendous richness are based on dualisms. Look at wave-particle theory. A simple dualism: photons are both particles and waves. A very rich conceptual ground. Rolonic theory is based on two dualisms, wholeness/partness and structure/stream. Lets start with the first, its probably easier.

Everything is a whole, with associated behavior. At the same time, everything is a part of a larger whole. A whole with parts is a system, so we're always dealing with systems of systems, how a system deals with its parts and how a system interacts with other parts within a larger system. Descriptors then describe a system's behavior; classifiers identify a part within a whole and relations between parts. "Ha!" you say. That's just meta data. And that's missing the point. Classifiers and descriptors are quite different and a good model of any system of systems implements classifiers and descriptors differently.

Now lets introduce a Rolon. This is the term we use for a part of a system and for a system with parts. (Everything is always both, so there's no confusion here.) The catch of course is that when you implement a model of a system of systems (which is to say, any interesting model of anything), the descriptors and classifiers are also Rolons. But never mind that now. Lets move on to the other dualism, structure/stream.

Everything is a structure. When you think of a system of systems, you envision lots of structure. But everything is also a stream. Say what? Yes, everything can be modeled as a collection of events which occur over time between Rolons. We are our history, hmm?

Lets look at something very simple--XML. You have the DOM representation, which is a structure, and you have documents, which are streams of characters. You also have SAX events, which can be used to create a wide range of structures when parsing an XML document. Conversely, you can walk an object graph in various ways to produce different event streams that can be used to create a wide range of XML (or any other kind of) document. This is what my earlier project, jxQuick, was all about.

So when you are modeling something, you sometimes need to take time into account. And this is rarely done systematicly. And that's probably the root cause of why we don't have a general way to model applications. So here's the skinny--a Rolon's state is represented as a structure, which we call a ledger, and its history is a journal of events. Or transactions if you will. Of course, you can recreate the ledger of a Rolon by replaying its journal. Or you can change the way the journal is interpreted and when you replay it you get a different ledger. (Norm calls this retrodiction, reinterpreting historical data in the light of present knowledge.)

Now there are some applications where the journal is of absolute importance, like a bank account. But I dare say, there are a lot of applications which would be far richer and natural to use with a systematic implementation of changes over time. Like the difference between a calculator, which gives you an answer that is only correct if you entered the right numbers, and an adding machine, which gives you a journal of the numbers (a printed tape) that you can verify are correct. I contend that software needs more adding machines and fewer calculators. :-)

And that's the basics of Rolonics. Breath deep. Remember how hard it was for us old Fortran and Cobol programmers to learn C++. The ideas are really simple. Wholeness (behavior, descriptors), Partness (names/relationships, classifiers), Structure (state, ledger) and Streams (transactions, journal). This is a way of looking at (modeling) the natural world, both mechanical and organic systems. But it is a twin dualism, so it is terribly simple and immensely rich in implications. It took me more than 5 years to get comfortable with Rolonics. Hopefully it will not take you as long.

The AgileWiki(3) then is being built using Rolonic concepts to model/implement applications. There were 5 generations of prototypes before this, each taking about a year to do, and each teaching me new lessons about implementing Rolonic models. And each with somewhat different capabilities. But this time 'round, its not a prototype. Should prove interesting!

Bill

P.S. Norm, I've used a lot of your phrases and concepts here, of course. As the author of Rolonics, you've left a deep imprint on me and how I think. --B

odds and ends

I've added some READMEs covering AW and the 4 projects under it. Generated the javadocs. Posted an ad on java.net for help. And generally prepped for a release, likely tonight (India time).

The rest of this week will be light. I need to pack for the trip and work a bit more on my taxes. I'll note that I still need to handle session timeouts in class Portal, but that will not make it into this next release.

Bill

Monday, April 17, 2006

multiple clients, reorganized projects

You can now run mulitple RMI clients. At the same time, even. Multiple clients for the same user and multiple users. (And I did add 2 more synchronization locks, but they're small.)

Further, I've reorgaized the code into 4 jar files:
  1. AwCommon--common to the server, the clients and even used by rmiregestry.
  2. AwServer--the application server and database.
  3. AwTextClient--the interactive text and script client.
  4. AwSwingClient--the Swing client.

Looking good. Note that I've now dropped the direct clients.

Looks like a servlet client is next on the list. This will give us a web interface.

Bill

Sunday, April 16, 2006

release, migration, RMI and schedule

  • Release alpha16 is out.
  • The svn at java.net is now being used instead of the svn at SourceForge.
  • RMI is working, though it needs more testing. (I have not yet tried running multiple clients.)
It has been a busy day. But I must say, I found RMI to be a snap! A one-line code change in the clients and a 5-line main method added to the Portal class in the Ark.

Just a heads up--I'm leaving for Anil's wedding on this Friday and will be off-line for about a week.

Bill

On the home streach!

Conversion to forms has taken a bit of work. Script client is working again. Next is login, which will again break... script client.

After that comes the release and then the migration of the code base from svn on SourceForge to the svn on java.net. And they want a copyright notice added to each source file. Sigh. But everything else remains where it is.

Then on to writing the servlet, or should I do the guestUI first? The guestUI will simply present an ordinary web page containing just the parent(s), children, lsecs and the Rolon's document. Should be pretty light weight. And useful for indexing, as well as making content accessible to web surfers.

Bill

Saturday, April 15, 2006

Fixed it!

I've fixed a bug in script processing.
I fixed the hang on startup after a crash.
I've fixed the caching problem with nested transactions.

If there is still a bug causing the DB to crash, I can't reproduce it now.

Time to fix the script client.

Bill

distributed, long-term transactions made easy

Programming in 5 dimensions opens a new door in transaction processing. Each activity initially creates a new locus. Multiple activities are allowed, without constraint. When an activity completes, the locus is folded into another (the trunk?) locus. If there is conflict in the folding, either the activity can be repeated or a merge operation can occur.

Sounds like science fiction to me. Each event creates a new alternative universe.

Actually, this kind of transactional processing is already quite common as an alternative to locking when supporting multiple writers, though only for short-term transactions. But the implementation here is much simpler.

The basic idea is that two loci, with non-conflicting changes, can be combined. This is the inverse of a branch, but remember that I'm talking about low-level database operations rather than a CVS where these operations occur at a much higher level. (Innovation is largely about granularity.)

Bill

composit views, folding

More on 5-tuple operations...

Consider that you have a primary locus but you are folding other loci into it. You need a composit view where each rolon viewed lists the various loci of interest in which it participates.

So you view a rolon with a primary locus of A, but which only participates in locus B. You can then elect to fold the changes of locus B for that rolon into locus A by applying the relevant JSecs. By this means you can merge loci which are not sexually compatible (loci with conflicts).

Hey, its just like a merge in CVS. Welcome to programming in the 5th dimension! :-)

Bill

loci, the plural of locus, the dimension of alternatives

Some discussion last night with Norm on 5-tuple space.

3-tuple: subject, relation, object
4th dimension: time
5th dimension: loci
6th dimention: 2-time?

(2-time is the dimention of intention, but lets not go there now. I've mentioned it here only for completeness.)

Loci is, in Norm's words, context. Well, everything is context so a bit more needs to be said.

Think of loci as branches in CVS or SVN. Think of it as the dimension of alternatives. And an enabler of hypothetical processing.

Consider you create a wiki page with a bunch of references. What is the minimal set of classifiers needed to best resolve those references? Sounds tractable to a genetic process, mm?

With a 5-tuple database, you should be able to get a journal listing for a given rolon across all loci. Sounds like a great way to do a branch comparison or merge hmm?

Now of course you may want to list a selected set of loci on a Wiki page. And of course that same page, for different loci, may list different loci. Not helpful?

Any given activity/transaction/JournalSection is applied to a single loci, so you should be able to list the loci where a rolon has participating JSecs. Better?

Just like a branch (it is a branch!), a locus is created at a given time from another locus. Asexual reproduction. Once a locus is born, it is an individual and will have its own history (Journal).

A non-conflicting merge of two loci occurs when there are no rolons with JSecs which participate in both loci. Sexual compatibility. A merge then produces a new loci. Sexual reproduction.

It will be a while until I'm ready for this. :-)

Bill

moving AgileWiki?

The AgileWiki has been accepted as a new project in the Java Enterprise community at java.net and has been placed in the enterprise incubator. So we have an additional URL: https://agilewiki.dev.java.net/

They do require that the code be developed there, so I'll need to drop the svn on sourceforge. And to access the site, you will need to create an account with java.net. :-(

Not to worry, this is not a big change. Downloads will continue to be on sourceforge and documentation, when I get back to it, will be at agilewiki.org. My hope is simply increased visibility within the Java community.

Lets see how it goes.

Bill

Friday, April 14, 2006

News in pleanty, good and bad

I've rewritten the script command.

The script client is now broken (out of date), but the script command works now with both the interactive text client and the Swing client. And it uses a form for the entry of the script.

The script command also works with commands which use forms. So you can write a script to register a collection of users.

The login command, because of the login events that it creates, will require some specialized code for it to use forms. So this will get delayed until after the script client is working.

And there are bugs in the database. It hangs or crashes at times and nested transactions just don't work. Developing forms has given me lots of experience in working with the database, especially odd cases caused by bad form code--which the database should be capable of recovering from!

So I'll be working on the database this weekend. Specifically, transactions. :-(

Can I say its still alpha? At least the idea of composable forms has worked out very well. This allows the application programmer to focus on the business logic, not presentation and not harry stuff like thread locks and transactions.

Bill

What's wrong with the semantic web

The semantic web captures static information nicely in a network of 3-tupal nodes. But information changes over time. Yes, you can simulate a 4-tupal network with three but it is a bit awkward. (Time being the 4th element.)

The AgileWiki is a 4-tupal system and captures changes over time. But this does not support reasoning or what if's. That requires a 5-tupal network. (The 5th element being alternitives--I like the term locality.) You can use a 4-tupal network to simulate a 5-tupal network but its a bit awkward. It requires a lot of posting, which is too slow to be able to do much. Mind, there's no practical way to simulate a 5-tupal network with a 3-tupal network.

What's a 5-tupal network like? Consider a branch in the context of CVS or SVN. Lets say we have 3-tupal documents under CVS, i.e. we can store static knowledge in a set of files. We can access prior versions, and that gives us time. And we can create/merge/compare branches, which gives us locality.

At some point I'd like to be working on a 5-tupal system, which would be the basis for real AI, mm? Now would this give us what Norm calls a 2-time system, or do we need a 6-tupal for that? Right now that's just too far out for me to even think about! :-)

Bill

What is the scope (applicability) of Rolonic Theory?

I find that rolonics does not seem to be very helpful in general programming, where the focus is largely on behavior. In contrast, Norm uses rolonics in just about everything--organizing keys, his file systems, etc. I think the key here is first class user objects.

When working on the AgileWiki, I find rolonics immensly helpful. It provides me with a powerful model for organizing topics into complex structures, and accessing them. The benifit that rolonics brings then is to things that are named. It is a theory of knowledge and so its innovative areas are in how the user wants to organize and access things and less about the things themselves except when those things are themselves organized structures which have user-named parts.

So rolonics does not play well in the OO space, and only begins to apply at the component level. But for Wiki pages, EJBeans, Portlets, etc., it has tremendous benifit.

Bill

a milestone

Registration now uses a form and works with the Swing client. Interactive text and script clients need updating.

Thursday, April 13, 2006

paying the price

With forms working now in the swing and interactive text client, login and registration are up for conversion--including updates to the swing, interactive text and script clients. :-(

Once this is complete I expect that it is time to implement a servlet client. Then I'll have four clients to maintain! :-(

But the good news is that client maintinance should be minimal after that, as the theory is that these clients are application independent. Of course, that doesn't apply to UI models (and I want to do both a wiki and a Rolonic UI model). :-( Hmm. Perhaps I should wait a bit more on the servlet client, at least until after these two UI models are done eh?

Bill

a nice milestone

The npjs command, which uses a form, is now working with the updated Swing client.

The Swing client is composing the form on the fly--and it doesn't look half bad! :-)

Slowly slowly the case is being made here for a very simple programming model, where display logic is completely decoupled from the application.

Bill

Wednesday, April 12, 2006

Smooth sailing

The interactive text client now handles simple forms, as used by npjs. I've also layed the foundation for a composable form in the Swing client. Everything is going smoothly and just falling into place very nicely. The display of the body disapears when a frame event is present and vise versa.

Bill

Tuesday, April 11, 2006

a bit more refactoring

I've now pushed events deeper into the API to facilitate the implementation of forms(under svn). I've also written a draft version of Forms (also under svn). I'm now working on the conversion of NPJS to use forms. But there's a lot of work left on the client sides.

I expect the interactive text client to go quickly. As for the Swing client, I'm thinking about having composable forms using a vertical box layout. That would make things pretty open ended, mm? But making it look reasonably good might be difficult.

Bill

Monday, April 10, 2006

Non-Performing Journal Sections (NPJS)

A non-performing journal section is the equivalent of a blog post or a comment. Till now, entry was made via the command line, one line of text at a time. Fine for a text client, but really yuck for a Swing client. That's been changed now. The Text client still works the same way for this command, but the Swing client provides a JTextArea for the user to edit. And no, I haven't implemented forms processing yet.

What I have done is change the abstract class Display to DisplayInterface. This allowed me to combine the display classes with the command classes which invoked them, and still keep commands stateless and threadsafe. OK, so I only eliminated 3 classes and one package, but every little bit helps.

Unfortunately the same can't be done with commands and the evaluators they invoke--evaluators are stateful. So we're going to have some dumb command classes.

An abstract form evaluator class is likely coming soon. First I want to redo the help command. It can be much simpler (i.e. eliminate the evaluator class it uses) and easier to use, too.

Another item on the short list is the ch command for creating/editing content, but I may want to implement it as a form--I've already got enough evaluator classes to convert to forms.

Frankly I'm delighted with this forms idea. It will seperate a lot of nasty code from ordinary applicaiton code. :-)

Bill

forms?

Thinking of wizards, there is actually a simpler patter that is common: present form, process form. Doing this with an evaluator class is insane--there are way to many things to get wrong!

Current candidates for forms are register, login and npjs, though there are a host more coming. Seems reasonable to develop a base class for forms. And it would be nice if this class served also as a command, so we don't need to have an extra class just to invoke the form.

(It is nice to have separate UI model, command, evaluator and display classes and interfaces, but its also nice to combine them where appropriate. Call it theory and practice.)

Bill

Sunday, April 09, 2006

on the dual nature of input

First, the changes:
  • Time now displays as a complete timestamp in the form YYMMDD-HHMMSS-mmm-cccc.
  • JSecs now use the time as their name.
  • JSecs use the cabinet name to form their pathname: /cab/time.
  • Fixed the Ents display.

On another front, as wizards will be a big project, I'm thinking I should write a servlet client first. I want to develop AgileWiki to support text, Swing and HTML input, so its best to start early!

Now about the dual nature of input. This is a problem for evaluators. Consider the input of a document. In text mode, the user (or script processor) is asked for the input line by line, while in GUI mode the user submits the document in one go.

Case in point--npjs. This command currently asks for the input document one line at a time. What is needed is to support both modes of input. Easy enough for the UI to indicate the mode, but I'm concerned that it could make for some ugly evaluator code. Perhaps I can use a specialized evaluator for document entry, and just stack them up?

Bill

Wizards!

On any table which has selectors, you can now click on a row and it is as if you entered the secletor. (This occurs lots of places.) So you can click-navigate your way around the ark. Is cool.

Now the new project I'm working on at Sun is EZO, which is wizard based. What's a wizard? It is a scenario where the user enters data through a series of panels, where the process is reversable and redoable (preserving previously entered data when you go back to a prior panel). Once the data is collected, an atomic transaction takes place (i.e. without further user input) to perform the specified operation. Only today I was struck by the thought that the AgileWiki needs wizards, especially when a descriptor unit is being created. OK, I'm a bit slow sometimes.

You will find the wizard library here. Now in terms of the AgileWiki, a wizard would be a subclass of Evaluator. Hmm. Lots of work.

Bill

change of direction, so what else is new?

I ended up taking the rest of yesterday off, and today I'm feeling much better for it. But I did have a nicel long chat with Norm. He's now running alpha15 and is suprised to see how much was there. Norm's involvement is always quite helpful--he's very good at breaking my code. :-) And it is always good to have some oversight. As the author of Rolonic Theory he understands where I'm headed, and as a user he's always pushing for ease-of-use. So he provides a good blended perspective, all be it as a power user.

This morning I split lists into lists and keyed lists, and updated both clients. I'm considering doing a bit more work on the Swing client to make things clickable, but first I need an rid command for navigating directly to a rolon via its record id.

At this point I think the top-level infrastructure is "good enough." I've had a lot of ideas lately about new UI models and the work that could be done there is endless. A real tar baby. So lets stick with a single UI model for now (less maintenance!) and skip RMI and go back to the meat of the thing.

Of course, if anyone is interested in working on the Swing code...

Bill

Saturday, April 08, 2006

Keyed Lists

Took the afternoon off after doing the release of alpha-15. Went to Forum Mall. Looked at some SiFi and Fantasy, but didn't buy an books. Had some rava (fried fish). Feel a bit refreshed--I needed a break!

I've got 3 classes that create tables:
  1. Ents is used to list the Classifier Entries in the header;
  2. Rolons is used for listing rolons (journal, children, parents, etc.);
  3. List for keyed and unkeyed lists.

The list class needs to be split into 2--a list and a keyed list class. When a row in a keyed list class gets selected, the key becomes the user input. So I'll want to change the help command, which is the only code that generates a keyed list for the various command groups.

Then I'll need to update both the text and swing clients. so much for the joys of having multiple client types. :-]

Bill

Friday, April 07, 2006

Almost there!

Still a few things to do on this initial Swing client. Display the time in the header, and handle docs and lists in the body. I'd also like to handle a click on a row in a table.

It looks OK, which is a whole lot better than the text client (which isn't saying too much). Moderately usable, which counts for a lot. After this I want to do a second UI model where the parents table is in the header. A minor variation, but allows me to work out having multiple UI models.

As usual, its all checked in under subversion. But I strongly suspect there will be a release tomorrow. :-)

Over all the Swing client was fairly easy to write. But then, I don't plan on doing too much polish this time 'round.

Bill

A bit of a cheat

Swing and NetBeans seem to want tables to occupy a fixed area. The default is to provide scroll bars for when tables get large. I'm used to the reverse, where a table just takes up as much room as it needs and the scroll bar is on the entire display.

Should I fight it? Not now. And if I learn to live with it, it's easy enough methinks to do the same in HTML, mm?

So my cheat then is to us a tabbed pane for the body and let each element (doc, LSecs, Children, etc) be allocated the bulk of the window when selected/displayed.

Now the part that I really don't like is that parents has become part of the body in the defaultUI for the default display. So be it! It can always be moved later to the header. Its just going to be ugly for a while. :-(

Now what are the implications for other UI models? Too early to tell. Still learning as I go.

Bill

A MobileUI model

The AgileWiki2 MobileUI is pretty small. There is the heading, which is only the pathname, an optional error, the command entry and the body. Once I finish the SwingClient for the defaultUI, I'm thinking that it would be a good idea to take a small side trip and write the mobileUI. Then we will have everything in place and working to support multiple UI models. The mobileUI model is indeed small enough to be able to say, "Why not?"

Now I very much want to do a 4-quadrant rolonic UI. But that'll wait--its a bigun. :-(

Thought for the day: "Architecture is a necessary evil!"

Bill

Thursday, April 06, 2006

Swinging good progress

I've now defined all the elements in a page, and even passwords are working properly (including challenge/response for login).

The header is still missing time, but the biggest hole is the body--its empty.

So it looks good. You can enter commands (such as they are), register, login, etc. You just don't see the content! Unfortunately, I expect that what remains is at least as much as what I've already done. :-(

I've set the body up as a scrollable panel with a BoxLayout. The content in the body event then will govern the creation of additional panels to be added to the body panel. And each time there is a new body event, the contents of the body panel will be recreated. (Unlike most other UI elements, which are simply updated.)

Meanwhile, I guess I'm still on target for finishing this by the end of the weekend. Then RMI???

Bill

beyond NetBeans: making it dynamic

The NetBeans GUI builder doesn't parameterize things the way I want, so I need to reconfigure the GroupLayout manager on the fly. Case in point: the amount of vertical space allocated to the error display depends on the presense of an error. Here's the code

Bill

Wednesday, April 05, 2006

Web pages + AJAX = Swing + GroupLayout

Two new technologies, AJAX and GroupLayout, have brought Web Pages and Swing close enought that an application need not concern itself with the type of client being used. And as we are developing an application platform, it would be foolish then to do otherwise--the risk would be to develop a platform that is obsolete before it is ready for production!

I'm finally off to a good start on the Swing. Much of the header is now being displayed (including a table of classifier entities) and command input is fully functional. Because GroupLayout allows me to take an approach where the GUI components are composed based on the XML content to be displayed this will proceed much like the work on events: a slow start, a moderately long middle and then a quick finish. By the end of the weekend a lot of the Swing client may just be usable. :-)

Cheers!

Bill

Tuesday, April 04, 2006

A small bit of Swing

Finally got back to Swing, and its starting to look like my idea about XML composable panels is working. But its still too early to tell for sure if GroupLayout is going to be up to the job. I'm still thinking this will work out great. (There is no way I would have attempted this with any other layout manager!)

All I've done so far is the header display for pathname and DescriptorUnitName. Easy stuff. Next up is a table of ClassifierEntries. Entry tables will be another JPanel and being able to compose with them will be great. If it works. :-)

As usual, all the code is checked in under subversion.

Bill

polishing the code to a high gloss finish

Things are looking pretty good. I redid error handling. Now its consistent--you always just throw a DException when there is a user input error.

UI now focuses only on display content. It no longer handles client-side processing requests--that's been moved into Session.

Session now validates the user request.

And DirectPortal is now just Portal and has been moved into the framework package. Portal handles all the user sessions for a single client.

Things are looking very fine. Time to switch back to Swing. :D

Bill

New top-level interfaces completed and working

I am happy to announce that the new PortalInterface and PortalWrapper have been completed and all known bugs are fixed.

I've also updated the intentions page:
http://www.agilewiki.org/wiki/uuid/TRZsvhqmYwiArfBDE6V6bUrJ

Bill

Monday, April 03, 2006

still tired from the weekend :-(

Tonight I put the uuid method in the misc jar, so it can be used by clients to create session IDs. And that's about it. I'm in no shape to start a project.

One final thought though. We can have a single method in the Portal interface, while supporting any number of methods on the PortalWrapper class simply by wrapping the client request in another event and attaching the extra parameters as attributes. Love XML, at least when its kept simple.

It does look like we're going to have a great client API for both Swing and Web clients. :-)

Bill

more thoughts on the client API

I've been thinking about how best to handle an applet server as the front end to the ArkDb server.

What if the client creates a sessionId? Then a (web) request can be handled with a single call:

processRequest(sessionId,requestDoc,uiName)

Note that if the client simply wants an initial display, the requestDoc can just be the empty string. And after the initial request for a user, the uiName should be the empty string.

We'll want a second method to close a session, though the server should also timeout idle clients. Another nice thing here is that a client server need only track the channelId for each user, using a single socket or RMI proxy for all users.

Now in cases where there is no need to maintain an open session, the sessionId can also be an empty string and the ArkDb server can simply close the session after servicing the call.

Bill

another change to the client api

What happens when following a link with a web browser from an external page? You need to open the channel and request the desired content... there is no initial request.

So lets eliminate the requirement for an initial request and move the initial UI name parameter onto the portal call to open a new channel.

And what happens then when you need an initial display? Just pass an empty command line!

Note that this fixes the bug I found in initial request (the UI doing ArkDb queries without thread control support by an evaluator). However, the whole area of UI instantiation (with a selection by name) needs to be cleaned up. Previously DirectChannel was part of UI, which is why the confusion. UI now is taking a secondary role of only managing the displays, so it should likely be selected from a table of pre-existing UIs by session--in the future there will be commands which allow the UI object used by the session to be replaced with another. Easy enough now that UI is stateless & threadsafe.

So it looks like I'm back to working on the interfaces. Again. Well it looks like we're very close, and it is important to get it right! I'd rather have incomplet code (i.e. the Swing client) than incorrect code.

Bill

access control overview

The UIs, Commands, Displays and Evaluators can all access ArkDb content, but only Commands and Evaluators may update ArkDb.

A many reader / single writer approach is used for handling threads, so it is important to restrict the time updates are performed. Updates can only be handled by commands marked as update commands and by evaluators.

Access control is managed by the active evaluator for each client. The UI can not access ArkDb except from methods invoked by a command or evaluator. (I suspect there is currently a bug where the inital display breaks this rule--something to look into tonight.)

Bill

quick overview

Here's a quick overview of the top-level architecture:

  1. Portal. This is a client side interface. I expect there will be an RMIPortal soon, but right now Portal is implemented by the Main client class. Portal is responsible for creating a new channel for each new client.
  2. Channel. Currently there is DirectChannel, but what we really need here is a remote interface. A channel accepts user requests and returns the response. A channel is the client's only access to ArkDb.
  3. Client. Uses the channel to communicate to ArkDB and formats the responses. There can be text/swing/servlet clients.
  4. ServerChannel. Doesn't yet exist because of the use of DirectChannel. It creates new sessions when there is a new channel connection and routes user requests and server responses between the client channel and the user interface.
  5. UI. The client may request either a UI object or a subclass of same as its user interface object. A client may also switch between UIs, but only one is active for any given session. UIs are threadsafe. They are responsible for the content of the server's response to requests, particularly the header and default body of the display.
  6. Session. Stateful. Manages a stack of evaluators (filters) for processing user input.
  7. Evaluator. Stateful. Parses user input, invokes commands and responsible for managing dialogs with the user.
  8. Command. Threadsafe. Invoked with a command line containing any arguments together with an optional document from the client. Updates ArkDb and requests displays to be processed.
  9. Displays. Formats data from ArkDb. Invoked only at the discression of the UI when a command requests it.
  10. Rolons. Persistent application objects residing in ArkDb.
That's a fair amount of architecture, but breaking code into smaller roles does seem to reduce the size and increase the clarity of the program when the interfaces are appropriate.

Bill

It's a new day!

I finally got to DirectSwing this morning. Hardly any code there, so it was easy to convert to the new interfaces. So then I did release alpha14.

I need to spend some time now on the Swing--there's not enough there yet for even a proof of concept. :-(

I still need to change the portal interface so the UI is chosen by name. That's the last piece before going to RMI. But I think the Swing code is higher priority at the moment.

I do very much like the way the code is maturing. These interfaces are getting to be fun to work with. I'm especially happy with the Script client, and how it processes the events it gets from the server.

Bill

Sunday, April 02, 2006

no release, no Swing

Its been a long and difficult weekend. I worked too much and the code & design suffered for it and that led to more overworking. I'm still working on the interfaces!

UI is now threadsafe.
The ScriptUI has been dropped and a ScriptClient has been added.
Found some old bugs, too.

Still there is one change needed to the Portal interface--the newChannel method needs a parameter which names the type of UI needed. Of course, that means that I need to build a hash map of (thread safe) UI objects. So I'll want another file which maps UIName to UIClass.

And still I need to update the Swing code I have, such as it is. But right now I'm bushed. :-(

Bill

Jived on Servlets

My vision for the AgileWiki is to be a fast, easy to use and extend, application and content server. A super Wiki, as it were, accessible via a browser, indexable by Google, Yahoo and the like, and with a full immersion (Swing) interface distributed via WebStart.

I figure the Swing interface is the hardest, so I've got to start there. But creating the servlets to generate HTML is still key to this vision, so they must follow quickly before development progresses much further.

Sounds like fun!

Bill

more cleanup

I've now got things to the point where RMI should be a piece of cake. The Portal interface now has a single method, newChannel, which returns an instance of the Channel interface. And that in turn has two methods, initialRequest and processRequest, which provide access to the server.

There is also a new DirectChannel class in the directclient package in the ark project which extends the channel interface.

The UI class also is now a complete class, rather than being abstract. There will no doubt be multiple specialized UI classes for different client interfaces, but UI provides the basics.

Hopefully all these changes will help make the top-level architecture easier to understand.

I still need to clean up the Swing client, at least to the point it was before, and then do a release. After that I need to spend some time on the Swing client. Then I'd like to implement RMI.

Bill

Saturday, April 01, 2006

Jived about Servlets

I want to start a direct servlet client soon, so I can be sure that everything works and works well with scripts, Swing and HTML. I have a vision of an application and content server that can

  • Be indexed by Google, Yahoo and the like, making the site visible and searchable;
  • Easily accessed via a browser for casual use, but fully capabable of running all the applications;
  • Accessible via a thin Swing client using webstart for a fully immersive experience; and
  • Integratable with other applications as a web service.

And it should be much easier to program to than EJBeans.

Bill

Script command

When you run a script, it now uses a script command. Its an interesting command as it uses a new session object to run the script and, by extending the UI class, uses itself as the user interface object while the script is running.

The script command normally produces no display unless there is an error. Then it lists the commands which were run, and the error produced by the last command that was run.

Script is an invisible command--you will not find it via the help command.

Another nice thing is that clients can now pass documents together with the command line, via the portal, user interface object and session to the active evaluator. Indeed, this is now what happens when you run a script. And this facility opens the doors for things like editing documents and tables. Its been on the todo list for a while, but was never an immediate requirement.

Perhaps tomorrow I can work on Swing like I had planned. Of course the door is now wide open for implementing RMI, and that would give a better testing environment. But after getting the swing client caught up with the text client, which shouldn't be much, I need to focus again on descriptors so I can start adding some commands. There really isn't a lot you can do with AW3 right now except create cabinets, journal and set access restrictions. :-(

Bill

a major refactoring

I've reworked text client to use the new PortalInterface. It is now ready to be used remotely, perhaps with an RMI portal. :-)

Lots of updates. Interactive text works, scripts are untested and the Swing interface is broken at this point.

I don't like the way I've reworked scripts. I want to do it right, and that now means having scripts run from an evaluator--where the evaluator is the UI. This will be a big step towards having DescriptorSections for scripts. Meanwhile, Swing is on hold.

Bill

Never blog after midnight

Talk about diminished capacity, I think I lost it last night. Context is maintained by the session, not the UI! Crazyness.

In the light of day however, I do realize that I need a portal object even in a direct portal. In DirectSwing, the Main class will do; in DirectText, I actually need two portals to handle the two different sources of input. This will help make the code more reusable when remote clients are supported.

Bill

Taking a step backwards

The UI currently holds the current context (i.e. the selected rolon reference and time). That was OK until we want to switch between UIs, like you can now in AgileWiki2. So I'm thinking about spliting context out of the UI.

The other area that probably needs work is response handling. This has been done quite casually up to this point. But I see a need for using an event structure there too, as
  • A response may include an entire document, and
  • the client may be remote.

Guess I'm still in the back and forth phase of things. No suprise--its still early in the game.

Bill