a small step

Got a nice email about the blog from a coworker in France today. He said that he plans on using the JFrame/BoxLayout technique in his next project that he's working on for JG.

As for the Frank's question about the first set of functionality in the Swing client, well its already working. It just doesn't have any functionality yet. My initial target is to display the Ark rolon using a username of Guest. After that maybe login and register. But this is going to be a slow slow process at the begining. :-(

My small step for today was to write a suddenDeath method on Main. You pass it an exception and it does this:

1. Opens a modal dialog box letting you know that the program got an exception and is about to crash;
2. Print the stack trace; and
3. Exit.

  public final void suddenDeath(Exception exception)
  {
    javax.swing.JOptionPane.showMessageDialog(
        this,
        exception.getMessage(),
        "Unexpected Exception, Going Down!",
        javax.swing.JOptionPane.ERROR_MESSAGE);
    exception.printStackTrace();
    System.exit(-1);
  }

This ain't much, but then its been a while. I expect the pace will pick up quite a bit as the weekend progresses.

Bill

Small steps, working code, test test test

Its been more than 5 years since I've done any swing. This is fun!

I've refined things a bit, having been forced to make my theory work. :-) I'm not using the create code hook like I said. Rather, I just create a empty JFrame with BoxLayout. Then I can just add another JFrame (this one built using the NetBeans GUI builder) and it just works.

The key to keeping this simple is BoxLayout--it gives the auto resizing you want to make the subordinate components using GroupLayout happy.

I'm still going very slow. But even small steps can take you far if you avoid going in circles.

Bill

Swinging it!

After the release of AgileWiki-alpha13 this morning I've been digging into the NetBeans 5.0 GUI builder and doing a bunch of web searches for additional resources. The problem is that the XML document describing the page is more dynamic and/or far less complete than is needed to do a swing front-end. Woops!

I really like the kind of layouts you can create with NetBeans, you've gotta work hard to do it badly. But these layouts assume a fixed set of components. That's a prolem. And no, I don't want to do something like SwiXML--the XML document should be independent of the client. And no, I don't want to transform the XML document, that's too much work.

The key to this puzzle is that you can specify the constructor of a component. So while a layout may be fixed, the contents of the JPanels can vary tremendously. So what I need to do is have a fixed content for each type of XML element. I need to segregate the role an element plays (given by the XML tag name) from the GUI component used to display it. We can do that just by adding a type attribute. Bada Bing!

A page has 3 parts: the header, the body and the prompt (though the order in the display will depend on the client). Now if the header is generated by class Rolon, you use the normal GUI header component. But if it is generated by the JSec subclass, you use the JSec header component.

Further complication comes when adding multiple interfaces to a client, but this can likely be handled by prefixing the type with the interface name and using a default for the element type when there is no GUI component associated with the compound type name.

I think this will work. I'll still need to enhance the display event generation a bit, but nothing like the changes I'd need to make for SwiXML. And I get to use the GUI components produced using NetBeans.

Happyness is! :-)

Bill

events, file lock, swing?

Events are done, the print and println methods have now been removed from the UI. Time now for a Swing GUI? I'm so tired of trying to work with a text display! But one thing I want to fix first...

You should never have two instances of ArkDb running at the same time on the same files. Its a great way to corrupt the database. So lets have a lock file which exists while ArkDb is running and which prevents another instance from starting up.

Bill

What's so special about AW3's OODBMS?

The AgileWiki3's ArkDb is an OODBMS withseveral unique features, the obvious one being that it tracks changes over time rather than state, providing an easy means to navigate structures in time and to restore structures to a prior state. But there's also something quite interesting about how objects are implemented.

First, let me point out a cheat. This is not a general OODBMS, but rather ArkDb only handles instances of the Rolon class and its subclasses, which is a pretty severe limitation given that Java does not support multiple inheritance. So to use it you must embrace it fully--you can't simply port a pre-existing application to it.

The key thing about the implementation is that the objects contain no data, except for an identifier. (And its a UUID--a random 128 bit string.) Rather, the data is kept in any of several caches. This is the key to speed and simplicity in a transactional environment.

The caches are aware of transactional activities. So when an abort occurs, these caches drop anything that had been changed by that transaction. And when a nested transaction commits, its list of changed items is added to the list for the parent transaction. So the cache never contains outdated data.

But it is not only the Rolons which use these caches. The btree on which everything else is built also uses a transactionally-aware cache for its blocks. This means that when an abort occurs, the btree code only needs to worry about restoring changed blocks written to the database file, without concern for the integrety of its cache.

Note also that these caches are used to retain calculated results (pathname, topic lists), and the caches support interdependencies. So when something changes, any cached results which depend on that item are dropped.

Putting this logic (and data) into the caches has made for a fast and yet reasonably simple OODBMS. This is the heart of AgileWiki3.

Bill

back to the mundane--some progress on events

I've now completed the default display (show) to using the new events. A slow start, but the last half went very fast. Encouraging!

Now tell me--how do you build a community? I seem to be off to a slow start in that area.

Discussion any one? :-)

Bill

turning the world upside down

Wiki's are interesting in that, for a wide range of content there is a fixed UI. One reason why software is so expensive is that we must expend so much effort on UIs.

AgileWiki(3) is intended as a platform for a wide range range of applications. It is highly extensible, but only on the back end. This is possible as it is based on Rolonics, which is a complete and comprehensive theory of knowledge and consequently fully applicable for most applications dealing with information.

Rolonics describes a rich but fixed set of ways to create and aggrigate structures, allowing for the creation of a specialized database optimized for the knowledge structures it uses. But even more interesting is the display of those structures, as this can be done with a fixed vocabulary (i.e. a single XML schema or DTD), which allows for a stable UI and makes the implementation of multiple clients (swing, web, etc.) a reasonable task.

I've been reworking the displays of AgileWiki3 to be event based, with an XML document passed from the server to the client for describing the display content. At first there were new events needed for everything encountered, but as the work has progressed, I've realized that the total number of events (read XML element types) is a fixed and relativly small number.

Methinks this is going to be disruptive technology of the first order.

Bill

RMI

I've been a bit undecided about the larger architecture, aside from wanting to keep it open ended. SOAP sounds ideal. But I think I want something easier to start with. And I'm concerned about what my ISV will allow.

I could do a custom network interface. Not a bad thought, especially if it is not the only interface. Might be an easy way to tie to a Python client.

For now, I'm thinking of a Java-only solution. One possibility is to have a servlet access the Ark locally. Another is RMI. I'm thinking the answer is RMI.

With RMI I can stay with the text client in the initial implementation. So I can focus pretty much on multi-user issues. And I am very fond of being able to make small changes and keep a tight focus. This approach also means I don't have far to go before getting something working--which I really appreciate.

An RMI server is especially attractive as I can then do a servlet client and a swing client. I like the idea of being able to do a mix, though I'm sure time constraints will limit this until we can get more developers to join the project. Sigh.

Bill

Fun with XML

Events have been moved over to misc, as they can be used on both client and server side.

I've also added a EventParser. It converts an XML document into an event tree, but it makes a lot of assumptions--its intended only for documents expressed by Event.toString. Using EventParser, we can now round trip from event tree to document and then back to event tree.

It was fun. And useful if/when we build a backend server around the Ark. But I'm thinking now that the easiest way to get started is to just create a client servlet and have it invoke the Ark locally. (Useful, as well as providing a much-needed multi-threading test bed.)

But now I've got to get to work, start my taxes and finish the conversion to events.

Bill

expressing XML

You can think of an event structure as a very simplified XML DOM. I've been polishing the toString method on Event--it now produces a very readable XML document.

To round out the event package, I'll need to add another class for converting that XML document back into an event tree so that I can round trip from an event tree to an XML document and then back again. This will let me pass event trees as trees over, say, RMI, as strings. (Which is much less overhead than trying to pass them as serialized objects.) So I'm looking at an old friend, SAX. Haven't used it since the Quick project and it sure has changed!

And yes, I got my papers organized. Phew!

Bill

Putting display logic back in the data model?

Display logic belongs in the data model, or so goes the old school of thought. There is some truth to it. However, formatting and layout are part of the view, though governed by the user's specifications.

The nice thing about event-driven display is that events do not deal with formatting and low-level events have nothing to do with layout. So its easy to put this part of the display logic back into the data model. And that potentially eliminates a lot of redundent code.

Well, I've completed the conversion of the display header to events. And moved the generation of the display event itself into scriptUI and interactiveUI. (And ScriptUI no longer displays classifier entries with its customized header logic.) At the same time, I've moved all the header formatting logic from the UI base class into the text client. Where it belongs! Meanwhile, the Rolon class is now handling the generation of pathname and classifierEntries events, while the session object generates the time event. (Its the session object which tracks the time context.)

Using events has allowed me to break up the display logic into parts and scatter those parts to where they are most appropriate, without anything becoming too cryptic. The interesting thing is that the client formatting logic would likely be a lot cleaner if the output was a web page--a lot of that formatting could easily be handled by CSS, or perhaps a JSP tag library. :-)

Of course, converting the display header is the smallest part of this conversion effort. But since I can do incrimental conversions and everything just keeps working, its not too bad. Hmm. Time to get back to sorting papers. Gotta get these taxes done. :-(

Bill

adding event magic to the framework

Events are part of the magic of Rolonics--stream/structure/stream.

Events are simplified XML elements. Each event object has a name (element name), attributes (name/value pairs) and a content (a list of events). Indeed, event.toString() expresses an XML fragment, so its ideal for use in transporting information across the internet.

I've added an events package which defines Event and has a Composer class as well. The Composer converts a series of calls (i.e. a call stream) into an event tree.

Then I wrote the TextClientIteration class, which accepts a page event and returns the user response. Currently the Page event only contains Text, Break and Prompt events.

Finally I converted the UIs to generate these events. This completes the event framework.

Now I need to replace all the calls to print and println into calls on the composer to construct a variety of non-text events and add the appropriate event processing logic to TextClientIteration. By this means I can move all text-specific logic into the text client.

And then I can define other types of clients! Hey, it feels a bit like magic. This is the key to supporting a range of client types, as well as the generation of TeX documents. Cool stuff!

Bill

a more descriminating script portal

I've now converted prompts over to being just classifiers. And scripts are smarter too.

When running a script, default displays are inhibited. Header displays are also inhibited except when there is an error or when context (or time) has changed. Makes it a bit more usable, I suspect.

Time then to do a release and at least start on my taxes.

Bill

a coupling issue

A number of evaluators have associated displays to which they were closely coupled. This has been addressed by combining the evaluator and display into a single class. To do this, display requests now pass a display object to the UI rather than a class. The evaluator then simply passes itself in the display request.

The next step in laying the groundwork for display events is to change the prompts to classifiers. It is then the responsibility of the UI to create the appropriate prompt for the user. By passing classifiers, the UI is now told directly what type of input is expected and can make adjustments accordingly.

Bill

too pretensious?

Thinking about what I've been saying. The claims don't seem to be justified.

I am quite excited about this implementation of the Ark. But it is still just an application server, and the extensibility of behaior does not seem to gain too much from rolonics. Individual rolons, yes. Aggrigates of rolons, yes. But not so much aggrigate behavior. Evaluators are the most interesting part of the framework, but are pre-programmed with a fixed behavior. I don't yet see clear to an evaluator governed by the progressive state of a rolon.

I think the thing which will eventually open the doors to the magic is a focus on games, which have interaction governed by current (and past!) state. Perhaps an adventure game. I don't know.

One thing I am particularly interested in after the basic architecture is descriptors, for validation, parameterization of display, and the creation of structures. A bit on the mundane side of things, but really solid stuff. And largely undeveloped in the previous version. But it is also an area that can be a disaster unless done right, and generally a real pain for developers.

Bill

framework architecture overview

Still things to do before I'm done with the architecture, though I've made a stab at cleaning up variable names. Time and past time for an overview of the architecture, mm?

1. clients

There can be any number of different kinds of clients. Direct clients are part of direct portals. But there could be swing clients, web servers, thin python clients, or even other web services.

2. portals

A portal knows how to interface with the client. There is already a single user direct portal, but there could be SOAP portals, RMI portals, etc. And a good portal knows nothing about the client except how to communicate with it--user displays are passed as events which the client is responsible for converting into swing objects, html, etc. (Direct portals being simple and fully integrated with the client, they just know too much!)

3. user interfaces (UIs)

A portal can have any number of different kinds of UIs, and typically a user will be able to switch between them at the command prompt. But for each active session, there is one active UI object.

UIs are responsible for soliciting appropriate display events and passing user input to the session object. UIs are pretty much stateless except that they are tied to a user and to a session object.

4. Session objects are responsible for all session state. There is one per active session. However, the session object also maintains a stack of user input evaluators which maintain additional (conversational) state.

5. Evaluator objects manage a conversation. The initial evaluator which resides at the bottom of the session's stack of evaluators is the command evaluator, which process commands. Evaluators communicate with the UI via the prompt.

6. Commands are thread-safe. There is one object for each command. Commands produce errors, update the ark database, push evaluators on the session's evaluator stack, and request displays.

7. Displays are invoked by the UI, sometimes, after a command which requested it completes. Displays may get state information from an evaluator (the top one in the evaluator stack) or from the session object. Displays generate streams of display events.

8. The ark database provides information mostly to evaluators, commands, UIs and session objects. Only commands and evaluators can update the database.

9. Rolons reside in the database, are operated on by commands and evaluators, and participate in displays. Commands are attached to the various rolon classes. Command scripts may be stored in the content of a rolon which is serving as a descriptor section for another rolon.

The intention of this design is to define an open and extensible application server for personal and collaborative applications, an Agile Wiki. And a whole lot more.

Knocking UIs into shape

Env is now called Session, which seems like a much better name.

View, previously TextView, is now the abstract class UI.

And the direct portal now has two UI subclasses.

What this all does is to begin to put the control flows into their new form. The UI is now the manager of the display.

What's next? Well, I need to clean up a bunch of variable names. I also want to start working on the new UI class and eliminate the displays.txt file. Commands will now request displays by passing the display's class object. Once all this is a bit more refined, we can focus on defining display events, so that once again we will not tied to a text display.

And no, I don't anticipate any more reorganizations on this scale. Though I do also want to move the header and default display logic (at least some of it) from the UI class into various Rolon classes. These displays should vary both by the UI mode/class selected by the user/portal and by the type of Rolon being displayed, so its a bit tricky to get right.

Bill

UI objects

The UI interface is now in place and the package structures have been simplified--view.text is now simply displays, and the two classes in view are now in framework. And the direct portal now has 2 distinct UI objects, one for scripts and the other for interactive use. Its looking good, but there will be more work on the direct portal once displays are converted to using events.

The next step then is to rework commands.

Bill

lets imagine

What's the next big thing in software? Perhaps it is wiki-based applications--they do seem to be croping up everywhere these days. But why would such a system (i.e. the platform for wiki-based applications) be limited to browser access? Why not a thin python client? And shouldn't it support scripting as one means of being user-extensible? This is my vision for the Agile Wiki.

Now why do I keep harping about rolonics and using rolonic terminology for everything? Rolonics is a theory that is helpful in describing persistent first-class user objects, their behavior (descriptors), relationships (classifiers), state (ledger) and changes over time (journal). And it is the only theory which is applicable. It is also complete, as it covers transformations and interoperability of complex systems (both are structure/stream/structure).

I know I've said this before, but I believe the reason why we keep reinventing things and creating ever-higher software stacks (servlets, session beans, entity beans, portlets, SOA) is because development is ad hoc. The industry as a whole lacks direction and has degenerated into fads. Software these days is all about fashion and if you're not working on the latest fad, you're nobody. This is not a good state of affairs. And it makes software very expensive.

I've become quite an advocate of Rolonics these last few years. It was developed by Norm Kashdan to describe things (objects) and knowledge systems. The power of software is in its ability to create models, which is also the power of language. And using Rolonics, I am convinced, provides a sound theoretical basis for software development.

I invite you then, and challenge you, to join me in this grand adventure, to reshape the software industry and indeed the way we think about the world around us. Work with me, learn more about rolonics, and put an end to software as a fashon.

Bill

UI Interface

The portal interface has become the UI interface. Package view has been merged into framework (both classes) and package view.text has become displays.

My plan is for the direct portal to have two user interface objects, one for user interaction and one for scripts, to drop the requiredDisplay method from commands (its not used), add a new navigates method to commands (to indicate to the UI which commands change context), and to have the UI call the display selected by the command (commands will call a selectDisplay method on the UI to achieve this).

This then sets the groundwork for making displays event driven--events will be calls to methods on the UI from the display.

I also need to take this weekend off for working on taxes.

Bill

nested transactions are working now

I found some outdated code in TransactionManager.bimage. Fixed it and everything seems to be just fine now. Scripts are now atomic.

Party time!

But its a bit too quiet here for a party. Rupali went home last night (by train, and it takes more then 24 hrs.) to help prepare for her brother's wedding the end of next month. Guess I'll just settle for a good night's sleep and a big grin.

Now if you really want to see me happy, then go and review the code and ask some questions. I don't think you will find another open source implementation of nested transactions that is as simple and easy to understand.

Now with only minor complications, I believe the code could be made to run ever so much faster, at least for the common case where transactions are not nested. But if no one is that interested in looking at the code, I see no point in making it a priority. And I see every advantage in leaving this code as simple as possible for now.

(On second thought, the speedup I was thinking of--which involves caching before images--will not work because on commit there is usually more than one block to be updated and so you need to write those before images in any case. Oh well.)

Bill

all is not well with nested transactions

I am using this test script now:

cch
restrict fudge
xx

It runs fine, except after the abort restrict remains set to fudge. :-(

So scripts are not yet atomic, even if they seem to be working. Needs work.

Bill

User Interface Mode Objects

It strikes me that the user interface mode object (UIMO) would be internal to the portal, so the rest of the ark/framework would be unaware of it. And in the case of a remote client, the UMIO would be on the server side.

A portal would have one or more UMIOs. Selection/switching to a different UIMO would be the responsibility of the portal, perhaps by a user event internal to the portal or by intercepting the selection command before a command is processed by the ark framework.

As I mentioned to Norm last night, I am very interested in developing a direct swing portal where, like the direct text portal, the client is local and only a single user is supported. This would allow us to use a dual pane view of an eariler incantation which Norm enjoys so much. (Left side is context; right side is content.) Later we can focus on remote clients, perhaps using a SOAP interface. Then we can have servlets use the ark as a web service, and even support .NET clients. At that point we can develop UMIOs which are independent of the technology used by the client.

Bill

what's pending

1. more testing of nested transactions.
2. time out for organizing papers, doing taxes.
3. give transactions names and pathnames.
4. define some additional capability, perhaps change password and set password.
   
5. rework all display logic to generate display events; change direct portal to use them.
6. insert user interface mode object(s) between the portal the displays; move header display (and perhaps default main display) into the interface mode object.
7. define a generic create based on name magic
8. classifiers
9. etc., etc., etc.

So much code, and only one life to give. :-}

Bill

progress on nested transactions

Nested transactions are just starting to work. :-)

Still need to do more testing, of course.

Bill

a new display architecture, random thoughts

Too much time spent on rearchitecting! Hopfully redoing the display architecture will be the last big one.

I had previously mentioned that an early version of AgileWiki used display events, which were then used to generate TeX output or a GUI display. But there are other considerations, too.

In the latest implementation, a good part of the display was driven by the mode of the display. So we could accomodate web browsing from a mobile phone or a desktop, novice and advanced users. This is applied to several areas, including the header information, default display and lists of topics. As well, the modal display needed to know the applicable commands and which commands might move the user to a different topic. Pretty fancy stuff, and we need to handle it all.

Now we have the additional requirement of running scripts, which need to be aware of when an error occurs and which probably run either silently or, in the case of an error, just display the list of commands which executed up to the point of failure.

In the case of a frame display, we would have portal events requesting a list of applicable commands, a particular heading, or the body of the display. Things like topic lists can be controled by modal variables provided by the portal and/or the display mode.

It seems like we need to have a display mode object (guest/beginner/expert/master/mobile/etc.) that sits between the portal and the display logic. It would handle requests from the portal (give me the header, the command pane, the main display), responding with a series of display events. This display mode object would provide the display parameters to the display logic, and capture the display events for the main display. Or perhaps, instead of having the command invoke the display logic as it does now, it just indicates the logic to be invoked when the main display is requested.

Now, how would a text portal work? It might follow something like this sequence:

1. request a command to be evaluated.
2. request the display of the header.
3. request the main display as determined by the command.

Bill

starting on scripts

The direct portal already takes one parameter specifying the optional script file name. A second parameter has been added to provide a user name--but it defaults to AdMin.

When running a script file, direct portal now first does a login. And the password is taken now from stdin rather than from the script file.

I've also been working on normalizing error handling so that an error can optionaly abort the script.

All fun stuff. But then, I haven't started debugging it yet. :-)

Bill

npjsRestrict

A new cabinet-level command, npjsRestrict, sets the NpjsRestrict classifier entry on the cabinet. This then restricts the applicability of the npjs command.

By this means we can limit the creation of nonperforming JSecs (previously remarks) on a per-cabinet basis. Just like we could in AgileWiki2.

Note that, while npjsRestrict also works at the ark level (Ark being a subclass of Cabinet), the restriction only applies to the ark itself an anything (other than a cabinet) below it.

And yes, now that the Ark has a descriptor unit, you can attach NPJSs to the ark.

Bill

Access control is working

I've done some limited testing on access control, and it is working. I'll hold off on further testing until I can edit LSecs, which is going to be a while I'm afraid.

So I guess its back to the direct portal to create a test environment for nested transactions.

Bill

Code for user groups roughed out

There's now a FileRegex class, as well as a ArkUsers rolon. There's even a method on Env to check to see if the user is in a particular group for the given cabinet.

Lots o' new code, none tested. :-( But its gotten late again. Time for bed.

My plan is to add checks to the restrict command. I've still got to figure out what's next. Perhaps working on the portal, so that scripts are atomic--nested transactions still need to be tested!

Bill

Well begun is more than half finished

There are now two more subclasses of Rolon: Table and TableDu. There is also a TableContent cache. And, of course, the Users table/LSec has already been moved directly under the Ark.

This then lays the groundwork for processing restrictions, though we still need a simple filename regex capability.

Bill

Etc is Gone

The Ark rolon is one of those edge conditions... it takes a while to get it right. Well, anyway, the Ark now has its own DescriptorUnits drawer which even holds its own ArkDescriptorUnit. The Ark rolon itself is now a subclass of Cabinet.

Lets see how it goes. :-)

Bill

took today off

I simply could not face the code today. It was too much. So I had a nice long nap this afternoon and then Rupali and I walked to the park and sat for a while. It was quite nice, cool and balmy and very green. And while almost all the park benches were full, it was not overly crowded.

Bill

Etc

There's a problem with Ark. JSecs under the Ark have no DescriptorUnits. At the same time, Etc is effectively the descriptor unit for the Ark.

Why not put a DescriptorUnits drawer under Ark, and eliminate the Etc cabinet?

Bill

AdMin can create cabinets, table caches

The new CreateCabinet has been attached to the Ark Rolon. :-)

Now, one problem with going further, and indeed a problem already with the restrict command, is that there isn't yet any logic to process a table. So there's no way to determine which groups a user is a member of.

And methinks that tables need to be cached, too!

Mind, these are multi-column tables I'm talking about which are stored in the document property of a Rolon. And there's another problem, too--no way to create/update these tables. So there's a bit of catch '22 here, too. But in the Etc cabinet I already have a users table defined. So there is a small starting point after all.

Bill

Commands are now attached to Rolon

No more commands manager. No more cmds.txt file. Commands are attached to the Rolon class, which now has getCmd and getCmds methods.

The next step is to write a create cabinet command and attach it to the Ark class. Of course, I'll want to update Validate with the logic to validate a cabinet name.

commands are now threadsafe

Phew! I just recoded all the commands to make them threadsafe. I think that was the biggest part of this change to integrate commands with rolons. Hopefully I can finish this tomorrow.

Then I can write the crc command and attach it to the Ark rolon. :-) After that, perhaps I could recode the direct portal to use nested transactions.

Bill

Fiddlesticks!

ArkDb and Rolon reference any number of Rolon subclasses. Sigh. So we roll framework into ark--a single jar file.

Nothing is constant but change itself.

Bill

integrating commands into Rolons

My first thought is that framework and ark must be combined, if commands are to be integrated into Rolons. Which means that ark would not be stabalizing at all. But I'm thinking instead that the subclasses of Rolon should be moved out of ark and into framework. That is sounding much better to me! The only question then is, what should be done with the rolons.txt file? I'm thinking only that it too should be part of framework, though accessed by ark. Should prove interesting.

I'm quite excited by this idea of integrating commands into Rolons, as I've been concerned with having such a large monolithic group of commands. For example, the Ark rolon would provide the crc command (create cabinet), as you must be in the context of the Ark to use that command. Lets see how it goes.

Bill

too many command objects

Currently each user gets a complete set of command objects at the start of a session. Ouch! This could make things rather slow as the capabilities of the Ark grow.

The good news is that commands don't do much. They don't need session state at all--that's kept in the portal, Env and the stack of Evaluators. So lets simply require that, like servlets, commands are thread safe. (Which I believe all existing commands already are.) A small change to the initialization process of Env and things are much better.

Now, what about commands specific to a type of rolon? We could have a static variable on a rolon (a HashMap, why not) which holds commands specific to that type of rolon. Another small change to Env and we've just made the Ark that much more extensible. And we've added another dimension to the applicability of commands.

Bill

even aborts are working now

Found a bug, fixed it, and now aborts are working. Even two aborts in a row causes no problem now.

I've also now restricted guest from having access to update commands.

Bill

its working :-)

No, its not tested very well. But it did process a help command. I'm happy--its bedtime. A nice way to end the day. I just wish it was all this easy. :-)

No, I'll not be testing nested transactions for a while. I want to make sure simple commands work, then add some new commands and THEN extend the direct portal to use nested transactions when processing a script file.

Meanwhile, its all checked in under svn. Enjoy!

Bill

First clean compile this week

I've finished roughing out the code for nested transactions. Now the fun begins.

Had to reorganize the cache classes a bit 'til I got it right. I had somehow forgotten that Block uses dependency and Pathnames and Topics needed transactional awareness.

Overall I'm happy with the code changes. Caches should work better now, besides doing more. And I eliminated the need to flush batches of Blocks--they're now only saved as needed to extend the file.

A good time to take some time off.

Bill

write and dependency caches

Good progress on TKS today, though it still doesn't support nested transactions. BTree is also nearly complete. And Cache now supports writes as well as purgs when a transaction aborts.

But the two uses of cache are now quite distinct. Topics and Pathnames make use of dependencies, while Table and Block depend on purges and auto-writes. So I'm thinking there should be a base Cache, as well as a write Cache and a dependency Cache. Again, my thought is to keep things as understandable as possible. (And only the write cache needs to be aware of transactions.)

Overall, I still believe I will be finished with nested transactions this weekend, though I'm sure there will be a lot of debugging needed.

Bill

AgileWiki.ark.tks.btree

Sent some time at lunch working on btree. The changes are almost complete. One thing I've done is to make btree a subclass of CacheFile. I'm also considering moving the contents of the cachfile package into the btree package and perhaps combining the btree and CacheFile classes--I think it would be easier to understand that way.

Bill

future intentions

Once transactions are working again, I want to stay focused on the Ark for a while, adding some commands (especially creates and destroy) to better exercise it.

I also want to change the direct portal so that, when working with a script file, nested transactions are used so that the entire script can be run atomicly as a single transaction. Then its only a small step to having scripts in DSects.

After that, we need dump/snap/restore.

Then its time to redo framework. The current architecture is simply too constraining. For example, I would like displays to be specific to the class of rolon being displayed rather than having a lot of embeded if statements--this will be far more extensible and indeed will overcome the last major restriction on Ark extensibility. I've got a bunch of ideas on how to do this.

The key idea is to turn displays into event generators and turn portals into event processors. I did this a few years ago and was able to suport a range of output formats, and even publish documents using TeX. So this is not new ground for me (unlike nested transactions). This is also a very rolonic approach (structure/stream).

Bill

cachefile roughed out

Gosh that went quick! Everything just fell in place. A rough version of package AgileWiki.ark.tks.cachefile with support for nested transactions is now under subversion.

My hope now is to finish roughing out the changes tomorrow and then start testing.

Bill

a transaction manager for nested transactions

New class: AgileWiki.ark.tks.cachefile.TransactionManager. (Now under subversion.)

This new class focuses only on handling the before image file for a transaction. Because of the narrow focus, its pretty simple. (And I didn't try anything fancy, either, like trying to cache before images.) And given a stack of TransactionManager instances, managing nested transactions shouldn't (!!!) be too difficult.

Lets see how it goes.

Bill

nested transactions is starting to get interesting

Had a bit of time at lunch (Rupali is taking English classes these days) and worked on cachfile initialization. Each record in the before-image file contains the overall transaction id, the block number and the before image.

First I read until the tran id changes, then read backwards and apply the before images to the file. I suspect that this reverse application should have been done before, so I may have uncovered a bug.

I'm starting to understand the complexities of nested transactions. I'll need to maintain a stack of before image start/end pointers, one layer for each nested transaction. Then when a nested transaction aborts, you apply (again, in reverse order) the before images for that transaction only.

Where it could get tricky is in deciding when to flush to disk. With a nested transaction, you've got to create a second before image record if a record is changed by both the outer and inner transaction. Now before images can be buffered in RAM (makes things much faster), only so long as you have not written any changes to the primary file. And you need to be sure that all the before images for a transaction are written out before any before images are written for a nested transaction. On the other hand, once a transaction completes, the associated before images, if still buffered, can now be associated with the before images of the outer transaction, and in the process, you can purge any duplicates. Uh, what was that?

There's fun, but this is sounding too much like work. Did I say I'd be done this by tomorrow?

Bill

AgileWiki.ark.tks.cachefile

I started work on the cachefile this morning, and I'm off to a good start.

It is nice to see the code getting simpler in some ways, as the cache package now handles the clearing of cache entries when an abort occurs. So the cachefile no longer needs to deal with restoring the content of invalidated cache entries.

Like the cache package, cachefile need to become aware of nested transactions. I figure I might as well move the functionality of the btree.TranFile class into cachefile. Sometimes having fewer classes makes things easier to understand. And it is hard to justify TranFile when everything under it must already be transaction-aware.

Probably another day on cachefile. After that, the btree package should go pretty quickly. So I'm still looking at finishing all this by the weekend. Of course, I expect there will be a lot of debugging at some point. :-}

Bill

Bricklin's WikiCalc

http://blogs.zdnet.com/BTL/?p=2141

Here's another Wiki-based web service. (I had previously mentioned JotSpot.) Looks like a future trend to me. :-)

Bill

A smarter cache

The code for cache has been completely redone. It is nested-transaction aware, purging updated cached items (cachables) when a transaction aborts.

Another big change is the use of a double-linked list. When you access an item, it is moved to the end of the list. (As before, when adding an item to the list, the oldest item is removed from the list.) Most significantly, now you can call clear on a cachable item and it is cleaned up and ready to go back into the pool of available objects as soon as its reference count drops to zero.

Holding a reference count on an item then no longer prevents the item from being cleared. This simplifies things and happens to work with the way the Ark uses cached items.

Bill

max pool size

I've reviewed the code and nested transactions with cache participation looks quite doable. I also want to add a maxPoolSize parameter for more flexible tuning.

Hopefully this will all be done within a week. But in the meantime, don't expect to be able to even compile the checked in code--it will be quite broken.

Bill

alpha9 release foopah

The alpha8 release was the first under svn and I managed to create an alpha8 tag. But with alpha9, I forgot all about creating a svn tag for it. Looks like I need to work on my release proceedure. :-(

Bill

JSecs and nested transactions, NPJSs

I expect that there will be no JSecs for nested transactions. Keeps things simpler--JSecs then match better with user-level activities.

One complication is NPJSs (previously remarks). You will not be able to use the npjs command within a script.

Bill

In for a penny, in for a pound

I've talked about script support for AgileWiki3, even supporting scripts within Descriptor Sections (DSects). But if we want to run scripts atomicly, AND WE DO, then there is little choice but to support real nested transactions. (Nested transactions in eariler versions of AgileWiki were really just single-level transactions--there was a lot of missing functionality.

This looks like a good time to address this issue, starting with the caching logic. Sounds like fun.

Bill

aborts: too high a cost

When the cost of an abort is high, then commands needs must be fully validated prior to entering the transactional context, adding to the complexity of the application. I'd rather keep the cost of aborting a transaction low, thus reducing the risk of application errors by minimizing application complexity.

However, I had not considered the impact of an abort on a cache until late in the game. So I want to go back and make the caches transactional participants, rather than taking a heavy handed approach at a higher level.

Bill

some difficulty

After doing the release, I was all for an easy day. Testing, general cleanup, nothing very difficult. But then I found a REAL bug.

Abort is corrupting my database, especially if you abort twice in a row. :-(

Oh well, there's always tomorrow. I'm calling it quits for today.

I do so like ending the day on a good note. :-(

Bill

An OODBMS

Well I finished breaking out subclasses of Rolon for now. Even have a User subclass. This approach has turned the ArkDb into a simple OODBMS. More to the point, adding new Rolon subclasses allows you to extend the API as needed for new applications.

So I'm done/working/commited, but its a bit rough, I'm sure. I need to take time out to review the code, cleanup the javadocs, etc.

Now I wish I could say that this is the last major refactoring. Hmm. Let me just say that I think we will see the Ark package start to stabalize now. But there's still a lot of work to be done in the framework.

Bill

On a role :-]

I was busy today. Already the subclasses of Rolon are JSec, NPJS, Ark, Cabinet, Topic and Role. Still a lot of refactoring and cleanup to be done, but I've been able to test&fix (and commit) as I go. And then I still want to add classes for LSec, DescriptorUnits and DescriptorUnit. Overall, I'm happy with the way things are taking shape. Its just gotten a bit crazy at times.

Bill

Looking nice

There's now a NPJS class (was Remarks, now Non-Performing Journal Sections) which extends JSec. And it has a CEnt (Classifier Entry) called Headline.

The npjs command has been updated--any arguments given are used to contstruct the headline.

And the default display now lists the time, user and headline for all associated NPJSs.

This all seems to be pulling together very nicely and feels very right. Of course, I'm still dancing around the edges of this big refactoring job of creating subclasses for Rolon. I've looked over the Rolon class and I don't see too much that will change there. Mostly the changes will be moving code out of the Ark class (soon to be the ArkDb class).

My objective is to push all the descriptor logic for rolons into the rolon class and its subclasses, rather than have it scattered about in various commands the way it was done in the previous implementation of AgileWiki. Looks like this will be achievable. So far, so good. Ark is next.

Bill

JSecs polished off for now, pathnames for JSecs

The API for JSecs is looking a bit better now. Next, two easy ones: NPJSs and Ark. Hmm. I'll probably rename the current Ark class to ArkDb to avoid a name clash and to add a bit of clarity. (The reference to the Ark instance in Rolon is already arkdb--I've been thinking about this one in advance.)

After that a small change in direction for a bit. (As usual.) I'm thinking of doing a bit more work on JSecs. They should have names (derived from their timestamp) and a pathname. But there are problems there. The context of a JSec may not exist--especially in the case of a destroy. And a JSec may be tied to hundreds of other Rolons, though generally all in the same cabinet. So the pathname should be in the form /cabinet/timestamp. But then there are also transactions tied to the Ark, like crc (and others involved in arkdb initialization). These can have a pathname of just /timestamp. These pathnames will work nicely with the idea that each cabinet has an associated log of transactions.

Bill

Rough and Ready

As my head hit the pillow last night, I realized that I'd left out half the code for JSec. Then I slept late (6AM). Still, I've managed to fix things up, though everything is still pretty rough. But it works. And I've managed to shift the JSec-specific code from class Rolon to class JSec.

My hope then is to continue to break up the Rolon class. There's a bunch of code there that applies only to specific rolon types. Having multiple classes will also give me lots of places to spread additional decriptor logic, rather than putting it in the commands like I did in the Python version of AgileWiki.

Bill

Type more basic than DescriptorUnit

Many a theory gang aft aglee when coded. Case in point. I made type more basic than DescriptorUnit when I started to depend on type when instantiating a Rolon. But trying to first lookup the DU just put things in a recursive loop.

The answer is simple. The Type descriptor entry must be set on a role itself. It is only acceptable to get the DEnt from the descriptor unit when creating a new role... sometimes. The additional problem comes up when creating the descriptor units for a cabinet. Resolving that just means doing some hard coding.

Anyway, I've made a start with JSecs, though its not tested as well as I'd like. (Its late.)

Bill

type vs usage

Type is somewhat orthoginal to usage, where usage indicates how something is used. For example, a given type might be usable as a Drawer, Folder or LSec. At the same time, we'll likely end up with many more types than usages.

I've already stubbed in the internal method for Ark.createRolon and the public static method Rolon.create (for narrowing, though it doesn't really), though the latter should probably be Rolon.createRolon. And I've made the constructor on Rolon Package-scope, as it should only be called by Ark.createRolon.

Probably the first type I'll work on is JSec, because it is so different from the other types--not having a name or pathname. Then perhaps a NPJS class, 'cause its easy.

I suspect some of these types will require a fair amount of refactoring. Sigh. Guess we'll just have to wait and see how it goes. But I expect to be able to move quite a bit of code out of Rolon and perhaps also Ark in the process.

This is all about descriptors (bejavior) and that is mostly what code is all about. The advantage here of working within a Rolonic perspective is the clear distinction it brings between classifiers/descriptors/ledgers. And that reduces the confusion, making it easier (but not easy, I expect) to come up with a good design.

The innovative areas of Rolonics are mostly in the area of Journals and Classifiers, as most software deals with Ledgers (state) and descriptors quite well. Still, the advantages of clairity should not be overlooked. (Yes Norm, I'm paraphrasing you again.) :-)

Bill

Rolon subclasses, factory, creates

Rolons are interesting in that they only have (or should have) a final reference to the Ark instance and a final TKS record id. Further, Rolons are not cahced, but only created as needed. (Topics for example, caches only the record Ids.) So as a Rolon's type changes, we can simply reinstantiate it as the correct class.

Lets then have a Descriptor Entry (DEnt) which names the Rolon's type. We can then have a table (like cmds.txt and displays.txt) which maps the type to the appropriate subtype. Then we can implement a createRolon which instantiates the Rolon based on the Type DEnt.

Now for narrowing, we can have a static create method on each subtype which first calls the comon createRolon factory and then checks that the instance can be cast to that subtype. Then we can place the various accessor methods on the appropriate subclass, and similarly distribute the logic for handling descriptor data.

That just might work.

Bill

.ark script files

Class AgileWiki.direct.portal now accepts a script file name as a parameter, so long as that name ends in ".ark".

At this point, I'm up against a wall. I've got to work on descriptors. :-)

Bill

restrict, a first update command

There will be hundreds of query and update commands, so the AgileWiki framework has been organized to minimize the code needed to write these commands. But today it occurred to me that I didn't have any sample update commands. So I wrote one, restrict, which sets/clears the Restrict classifier entry. As well as being a sample, it helped me debug the framework. (And working code is always easier to understand, yes?)

I've also reorganized things. Commands are now in one of three packages under AgileWiki.framework: apps, queries and updates.

Tomorrow maybe I'll work on the scripting portal.

Bill

scripting priority

NPJS is done, sans access control. So I'll need to get back to it. My intent is to use NPJS in fact to drive the implementation of access control.

But I want to do some work on scripting. A script would be either an external file, an LSec in the DescriptorUnit, or a DescriptorSection (DSect). My first thought is to work on a variation of the Direct portal that works with external files and creates a nice scenario file. Useful for documentation, and perhaps also regression testing.

Bill

JSecs, NPJSs and Remarks

I had a nice, if brief, chat with Norm yesterday. Unfortunately his network was down at the time. One of the things we talked about was the role of Non-Performing Journal Sections (NPJS) vs Remarks. There's enough convergence here that I'll be dropping remarks all together, but using the access control model of remarks for NPJSs.

First, the Restrict classifier entry for JSecs in general will be set to the name of the user who created them. So only that user (or a member of the admin group) can modify a JSec.

The second change is that anyone (except Guest) will be able to create a NPJS anywhere, unless otherwise directed by a NPJS descriptor entry on the Cabinet.

Third, like Remarks before them, NPJSs will be listed in the default display.

Now I've already got NPJSs working, sans access control. So I'll be working on these changes next. None of this is very exciting, but it will get quite interesting later when we can do tag matches on JSecs.

Bill

introducing Classifier Sections (CSects)

Norm made a comment that tags are CSects. That got me thinking.

In eariler implementations of AgileWiki, we had a variety of rich classifiers for expressing relationships: names, includes, tags, matches, -tags and -matches, each with its own specialized implementation. Further, there were limits imposed, like only being able to assign a single value to a tag. Rolonicly, these are all CSects. Perhaps we should go for a more uniform implementation in AW3?

Lets have CSect rolons. Usage is "CSect". And they are first class user objects. Then for each type of CSect, we would of course have a different DescriptorUnit. This will help especially in the implementation of the ApplicativeContext, which would then simply be the ordered list of CSects. Now it is easy to have more than one CSect for a given tag, each with its own value. It also becomes easy, or at least reasonably possible, to extend CSects to include other semantic relationships.

You may have noticed that to date I have not implemented any of these CSect types except for tags, which is acknowledged to be a broken implementation as I want to reduce tags to being Cabinet in scope. So there's not a lot of code to be ripped out to do this.

Norm, what do you think? With JSects and CSects as first class user objects, AgileWiki3 should get pretty interesting, mm? I'm thinking also that this should make AW easier to explain from a Rolonic perspective. Its really gotten to the point where everything in AW3 is clearly identified as Classifier, Descriptor, Ledger or Journal, with structure being a special case of Classifier.

Bill

going slow

The new Rolon class has been commited to subversion on SourceForge and subsequent testing has found mostly unrelated bugs--which have since been fixed. And what, with the completion of user registration and login, much of the groundwork has now been completed. Its just about time to start cranking out functionality at the command level. But not quite. We're still missing most of the descriptor logic, which for now can be put in the Ark class.

I started working today on the npjs command. This command creates a JSec with an associated document. And its nearly complete, save only the code to check to see if the user is allowed to post the JSec. (JSecs used to be called transactions not too long ago.)

Now the interesting thing about a npjs is that it can be posted on any rolon (except the Ark rolon, Data). That includes Cabinets, Drawers, Folders, Pages, LSecs, Remarks... and other JSecs. And yes, I'm having to enhance the display logic to handle the latter. :-)

My intention here is to focus on npjs for a while and use it to build/test some of that descriptor logic that is still missing, particularly in handling the Restrict classifier entries.

After that, I'm thinking about building a variant of the Direct portal that would read script files and create a nice scenario text file. Handy for regression testing, generating documentation, etc.

Bill

New Rolon objects

The refactoring is nearing a rough completion. Compiles are clean, but that's the best I can say for it. This was a huge refactoring of the Ark class.

I've wanted to separate base logic from descriptor logic and I've achieved that in a way that is typical for oo programming. The Rolon objects are dumb and stateless, being only wrappers for a reference to Ark and the TKS record id. Each user session will have its own copy as needed, so they are easily instantiated without any need for synchronization.

Descriptor-driven logic will remain in the Ark methods, Rolon objects serving only as a proxy for the persistant data.

What I've done then is remove a huge chunk of code from the Ark class and placed it in the Rolon class--about 75% of the code in fact. This is quite fine, as I expect the Ark code base to grow substantially as we add descriptor logic.

The other thing I've achieved is to put a friendly object face on Rolons, making the command, control (evaluator) and display logic easier for most folk to read and understand.

One of my goals in AgileWiki3 is to keep descriptor logic centralized, rather than scattered in command logic and various other places. My hope then is that the methods in Ark will be the only place where descriptors are processed.

So for example, a setLedgerEntry method on Rolon would simply set the value of a ledger entry. But a similar call on Ark would perform validation. I'm not entirely comfortable with this. An alternative would be to use a factory method on Ark for creating Rolons and use a subclass of Rolon to add smarts. For example, a createJSec method would instantiate a JSec subclass of Rolon that contains the JSec classifier access methods as well as descriptor logic relating to JSecs. But this sounds like a subsequent refactoring project. First I want to bring this one to a close. There's always room for subsequent improvements, though hopfully they will not be as substantial a change as this one!

Figure another day or so until I do the commit for this change.

Bill

a very busy day refactoring

Spent the day refactoring Ark. Its been split roughly into 2 parts, the new part being a Rolon class. Got the ark package to recomplie finally. Tomorrow I get to refactor framework.

No, I haven't checked this in. You don't want to see it in this state anyway.

Tired.

Bill

Timestamps and then Rolons

I've implemented the use of the Timestamp class in place of a timestamp string, with Timestamp.NOW representing current/latest clock time. Looks good.

Now I want to create a Rolon class and move a bunch of methods off Ark. Having rolons as objects may help make the code a bit more readable.

Bill

login, too many strings in the API

Ok, we've hita milestone, all be it a small and early one. The logon command works and Login events are created (as JSecs).

I think its time for me to do another alpha release. Then I want to change everything (as usual).

There's too many string arguments in the Ark API. Its not fun. So I want to introduce two new classes, RecordId and TimeStamp. Just to add typing to the arguments and a bit of clairity to the code.

Bill

login, DescriptorUnits

The Ark class really doesn't deal with descriptor units, while that is the intended focus of DArk. Consequently, I'd really like to move descriptor unit creation (triggered by a call to makeCabinet) up to DArk. But perhaps not today.

Now that new user registration is done, I really want to work on user login. Its just wierdly disfunctional having one without the other.

Bill

New terminology

The terminology I've been using has been slowly changing. Its differs somewhat from Norm's terminology and also from the terminology of AW2. I should hit the highlights.

First, Entries are always name/value pairs. (But the converse is not true. Not all name/value pairs are entries.) There are classifier entries, descriptor entries and ledger entries. Now not all classifiers are entries. Tags are classifiers but they are not classifier entries. (Tags are indexed, but entries are not.)

Next, there are the LedgerSections (LSecs) and JournalSections (JSecs). And what I previously called a transaction is now called a JSec. LSecs and JSecs can have LSecs, Remarks and documents as part of their state. And like all roles, LSecs and JSecs have a journal of JSecs. (Its strange to think of a JSec changing over time, but it can. For example, you can update the tags on a JSec.)

I've had a busy day. Mostly odds and ends. The weekly grocery shopping, a dental visit, some new AW3 commands and a lot of cleanup, like changing the Tran usage to JSec.

Bill

rolonic advantage

One of the drivers behind using Rolonic theory for programming is its completeness. In rolonics, everything is a journal, ledger, descriptor or classifier. And everything is a rolon. So there is only so much to be implemented to achieve completeness. With incomplete systems, you are always inventing artifacts to serve special needs because programming theory is so incomplete. This especially applies when dealing with time.

I woke up this morning thinking that, with journals being first-class user objects, we no longer need login events. Journals/transactions ARE events in time. Then I realized that I've created a bunch of special case attributes on transactions where I should have just had classifiers and perhaps even tags. Gotta go back and clean that up.

Finally it occurred to me that a tag match which matches a transaction could be the basis for event programming, the newly created transaction then triggering some activity in the role to which it matches.

Rolonics is so very simple and so universally applicable that its hard to see it sometimes. I've always said that the obvious takes longer.

Bill

thread control--another small milestone reached

The Ark is intended for use by either a single writer or multiple readers. Mind, there's a lot of optimization that could be done to handle multiple readers better, but that's the intent--the same as the previous version of the AgileWiki.

Milestone reached--single writer/multiple reader thread control code is now in place. Gosh, we could turn it into an RMI server pretty easily, if only it did something. And I think getting it to do something is higher priority. Though it would be nice to do both.

Turns out, most of the thread control logic goes into the Evaluator classes. That's been done now, and they can serve as examples for future evaluator classes. (Like login.) Mind, there's still some work to be done on user registration. It works, but with no security what so ever. Gotta fix that.

Bill

Evaluator classes, thread control

Evaluator classes receive user input and decide what to do with it. Active evaluator objects sit on a stack in the Env object and together comprise a large part of the user session state.

The bottom evaluator in the stack is always CmdEvaluator, and its job is to parse command lines from the user and invoke the appropriate command.

Conversly, the help and register commands (register is now working) invoke the HelpEvaluator and RegisterEvaluator respectively.

An evaluator is a state machine. It is responsible for any complex interactions with the user. It can do anything a command can do, but it can't display anything directly because it is not specific to any particular portal. For displays, commands and evaluators must invoke a view object which knows how to communicate with the portal.

Why do we have commands? Because commands are easier to code, and most commands are simple. Normally a command just parses the command line for arguments and performs some operation on the Ark or invokes some view. Usually there is no need for a state machine to manage this.

. . . . .

Now the Ark is intended to operate in an environment with either many readers (query commands running on multiple threads) or a single writer (an update command). Commands all declare themselves as being either query (the default) or update. It is the evaluator then that is responsible for thread control. In the case of CmdEvaluator, it must look at the command to determine if it is a reader or writer and handle thread control appropriately.

Note that while the Ark and the commands are inside thread control (this keeps them simple), everything else is outside thread control. But Env and the evaluators are unique to a single user session, and should be single threaded as a result--that's the portal's responsibility.

One of the catches to using evaluators instead of commands is that they are outside of code control and must manage it themselves. This adds considerably to the risk of having bugs in an evaluator. Fortunately most things can be done using a command.

. . . . .

I think it is time I start looking at thread control. We already have 3 evaluators which will need to be updated so that they properly manage thread control. Its time.

Bill

A place for everything, and everything in its place

In previous versions of AgileWiki, we had descriptors and, all be it incomplete, a bunch of descriptor logic scattered about. All very ad hoc.

I've just created a subclass of Ark, DArk, which is (hopefully) a good place to put all that descriptor logic. And it is now DArk, not Ark, which implements CmdArk.

And if it is better organized, perhaps it will become more complete. (Currently DArk is an empty class, but give it time.)

:-)

Bill

Less is more

The Ark no longer automaticly creates the Etc and Home cabinets when first created. Rather, this is now handled by an Init class in the framework. The idea here is that you might want to use the Ark in a program as an embeded database and don't need these cabinets.

The question in my mind now is DescriptorUnits. Descriptors are used largely for validating commands. Perhaps we need a layer above the Ark which deals with validation and other descriptor-governed behavior.

This is not a show-stopper right now. In eariler versions of AW, descriptor logic was spread across several modules, including commands. All very ad-hoc.

Perhaps all we need is a wrapper class where we can put all the descriptor-related logic.

Bill

keeping it simple for portals and clients

Another "Duh!" moment. User registration and login can be simple applications. Portals and clients then only need to be aware when a password is being requested. The evaluator class then sequences the requests for user name and password.

Bill

the more it changes

More thoughts on restructuring the jar files. I'd like to keep the jar files "pure", so there are not a lot of inapplicable classes in a jar file when you go to use it. Smaller jar files should make it easier to find things too, if there is a good top-level structure.

First, I'm thinking that each portal and each client should be in its own jar file--typically I suspect that you would only be using only one portal in a server. So the direct portal should have its own jar file. One complication here is that direct is also a client, so code common to direct and a text client should again be in a separate jar. And I already have two such classes for handling the entry of passwords.

So the current code then gets reorganized into 4 jars:

1. Ark,
2. Framework,
3. Common text client classes and
4. direct text portal.

And the current main then gets moved to the last jar file. But note that common portal classes would remain in the framework jar.

Its a bit more structure than I had previously envisioned, but it should help keep things well organized. And that's important, as I expect this all to grow considerably.

Bill

main, ark initialization

The main method has been moved again. Its now on the Direct class. But that has moved too--its now at framework.portals.text.direct. Perhaps its in the right place now? This main is really only to start up the direct portal. Later, when the framework is run as a backend application & database server, we'll need another main method for starting up the server.

I've also been thinking this morning about the creation of the Etc and Home cabinets. They will be used by the framework, but perhaps not by every application of the Ark class. There could well be single-user applications of an embeded ark. So perhaps the code that creates these cabinets when the ark is empty should be moved into an init class in framework--wouldn't be more than a few lines of code, in any case.

Headed out to the office early this morning, so I didn't get any code written. Besides, I'm still gearing up for the registration command. Should be fun. Last night I added a 1-liner, initializing user to "Guest" when the Env object is created. Note that Env holds most of the session state of the framework. (Well, of course, the portal needs some session state. But mostly that's just a map to the Env object for each user.)

Bill