New Home Page for AgileWiki

With the release going out today, the database is now fully scalable. Time for a home page which sports a feature list: http://agilewiki.sourceforge.net

The big change included in today's release, 13.1.0, is that element text content (text or binary) is now implemented using a b-tree. No problems with content that is hundreds of megabytes.

If interested, be sure to join the AgileWiki community at http://agilewiki.ning.com/

Bill

P.S. I just moved this page because of an access control issue.

Putting Magic into Software

http://agilewiki.ning.com/profiles/blogs/putting-magic-into-software

Web3.0 Business Model

http://agilewiki.ning.com/profiles/blogs/web30-business-model

AgileWiki on Ning

I've just created a ning network for AgileWiki: http://agilewiki.ning.com/

You are welcome to join.

Bill

Rolon Basics

Just completed a new section to the User Guide, Rolon Basics:

Headline - A Brief Description

Context - Rolon Context Drives Everything

Names - Names Depend on Context

Journals - Recording Changes and Other Events

Realms - For Organizing Rolons, and More

UserAccounts - An area for Each User

Relations - Building Complex Structures

AccessControl - Privacy and Control

UserGroups - Advanced Access Control and Common Work Areas

Rolonic Software Engineering in Brief

1. Common Data Structure - Everything is implemented as a Rolon. This includes commands, journal entries (which capture activity) and services. All Rolons, and only Rolons, are user objects.
2. Flexible Structures - Structures of Rolons are built using parent/child relations. Additional, arbitrary relations can be defined and used to interconnect Rolons. One such relation, Applicable Context is used to extend the namespace of a Rolon beyond the context implicit in the Rolon's location.
3. Open and Extensible - A Rolon can be expressed as an XML document and is implemented by binding elements to Java classes. Plugins are used to define and extend these bindings. All Rolons implement the same life cycle, enabling the composition of complex services from structures of Rolons.

Rolonic Software Engineering provides a systematic and comprehensive approach to the implementation of fully interoperable services, which is exactly what we need to implement Web 3.0.

ElementModel release 12.4.0

Access control is now in place.
Relations reworked to support incremental inferencing.

Home Page

The end of programming as we know it

I've just added a new page to the wiki which I think you will enjoy. It may well be the ultimate disruptive technology. :-)

Everything Just Works Together

Open letter to AgileWiki developers

Everyone,

I do hope you all can find something of interest below that you to contribute to. This list is just off the top of my head. I'd be more than glad to discuss other projects as well. For example, we need to be able to mirror the content of one system in others. Lots more coming, you can count on that.

Bill

Password Management --Bill

Problems with a p2p network of extensible nodes is that there is no central authority that can be trusted. You end up with too many passwords, as usual, for access control.

But you can trust your own client software, and if you use a public web service, you likely trust that as well. So why not have your point of entry into the network manage your passwords?

Likely also, you can group some of those hosts together and use a common password for them. Passwords then are assigned to individual hosts or to groups of hosts. And when you change passwords, that change should be communicated silently to all the hosts in the same group.

So we end up with something very much like single-signon, but where only the user needs to trust the point of entry. And we can use passwords to sign the messages as well.

I expect to have this complete (except for signing messages) in a day or two.


Web Front End --Naji

This is a huge project. Integration with Jetty, replacement of Browse with Comet. To date, a simple hello world has been released. I expect to participate in this project as well, but not any time soon. I expect that there will be pleanty of work here to keep any number of developers busy.

I already have an ISP where we can run this.


Access Control --Bill

With Web 3.0, you no longer need large capital expenditures to provide a service--the number of computers providing the service grows with the number of users. But think about it. If I'm keeping important information in my ark/repository/database, why would I let just anyone come and change it? And some of that information is confidential too!

For users to open their systems and really collaborate, we need access control. I've done this before and with relations already built in, it will not be hard.


Wiki --Bill

This is the beginning of semantics. As the repository is somewhat hierarchical, there are inherent problems in building a wiki on it--hierarchical wikis are always a good idea gone wrong. The fix is adding an applicative context, which gives you control over the namespace each page can use for referencing other pages.

I'd rather be writing docs than working on this project, so yes, I'd welcome the help here.


RSS Aggregator

The idea here is to feed the ark with content from multiple sources (information fusion), do a keyword search on the content and organize the incoming material on that basis. Norm (the father of Rolonics) has as an example over 200 feeds which he monitors. This would be a big help for him (our test user) and many others like him.

This project could be the first real application of AgileWiki--nothing else is needed. It is time to start this project now. First step, determine which rss aggregator(s) to integrate with.

Who wants to get started on this?


JXTA / JXTA 2 Integration

The current com package (nio sockets) might work in a business, but not out in the wilds of the internet. JXTA looks like the way to go. I see this as a necessary minimum to be a real Web 3.0 player.

I'd like to finish reworking the message formats (adding digital signatures) before this project gets too far along. But that shouldn't take too long.

Who wants to get started on this? I already have an ISP where we can run the core servers for this.


Developer Docs --Bill

By the end of March I hope to start working on this full time. But it would be very helpful if I could get a bunch of questions from everyone so I have some idea where to begin. I mean, the code all reads so clearly for me, but I suspect that is not the case for everyone else. To do a good job when writing, you need to understand the needs of the reader.

Everyone please, help me out on this. Thanks!


Email Client

I've worked in companies where everyone spent 6 hrs a day (no exageration!) reading and organizing their email, and a lot of those email were "things you might need to know" that were sent to everyone. Very few emails actually needed to be read immediately, but they all needed to be sorted out and organized. What a waste of time!

Integrating an email client into AgileWiki means that you can share not only the content, but the organizational structure. Again, this is all about information fusion and creating a useful organization of content. This could be a big time saver and an important application.

Having done this before, I'll note that the hard part is in presenting the email nicely. Seems like every email client structures the email slightly differently.

Any takers for this project?


Inferencing --Bill

Reasoning systems really aren't that hard to do. The tricky part is making them incrimental, so as the information changes, the inferences can be adjusted without having to start everything over again.

The relations already built into AgileWiki will be a starting point. And applicative context, which is part of the wiki implementation, is done, that will be the next part.

This will be a fun project, but we'll not be ready to start it for a while.

---

Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here.

Why everything "just works together"

With most software projects, if you have N options/features, the order of complexity is on the order of 2**N. So long as N is small, things go well, but as you add options and features, the complexity quickly gets out of hand--integration then becomes a black art. In contrast, the complexity of this project is on the order of b+N, where b is the complexity of the base system. That b is a bit large, so it makes it hard to come up to speed, but as the project grows, the overall complexity is proportional to the number of options/plugins. This is an astonishing result.

The technique we use to achieve this is by simply binding classes (and other configuration data) to element types. Each plugin defines new element types and also extends the configuration of pre-existing element types. The binding is all done in the .cfg file, which is generated from the .plugin file.

Now when the program first starts (empty database), it creates the ark root element, which contains configuration data about various sub-elements and child rolons which are to be created. These are created in turn, recursively, to generate all the architectural rolons needed to run the ark with a given set of plugins. Note that plugins never delete a pre-existing element type, nor do they ever change the binding and configuration data of an element--they only add additional configuration data. This is key, as it provides most of the decoupling we need to have a truly open and extensible platform where everything just works together.

http://agilewiki.wiki.sourceforge.net/

Twitter for AgileWiki development progress

We've started using Twitter on the AgileWiki project.

The links to the twitter accounts of the developers can be found at the bottom of this page: http://agilewiki.wiki.sourceforge.net/

Identity for web 3.0

http://agilewiki.wiki.sourceforge.net/Identity

I've been looking at web 3.0 and find that I very much agree with the ideas. I would categorize web 3.0 as being a p2p system which supports multiple points of entry (home, office, cyber cafe), where the nodes support information fusion, have pluggable applications and some native reasoning. And this is exactly what I've been working on for so many years now.

Today I've been thinking about an easy way to validate user identity in such a network. See the above link for details. It is reasonably easy to do and I've introduced only one new idea--categories of passwords.

Element Model release 12.0.0

The renameChild command is working again.
Dump no longer writes out prebuilt rolons.
Changes to the basic architecture are now restricted, as changes not preserved when migrating to a new release via dump/load are no longer permitted.
New Plugin interface.
New ConfigurationManager converts a list of plugins into a configuration file.
Keywords are now broken out as a separate plugin.

With the new plugin facility it is now trivial to configure a program. And for each new service/facility/application, you create a new plugin.

The utilities have been revamped as well.

Rolonic Software Engineering

Finally completed the operational theory of the element model. I do hope you find it helpful.

Roadmap for ElementModel and AgileWiki4

A comprehensive road map for Element Model and AgileWiki4 has been added to the home page. Inferencing, a mail client and versioning are included.

The development team (2) is far too small for the work planned. If you are a Java developer, your participation would be most welcome!

Element Model release 11.0.0

Element model databases are now crash-proof.

no design time

After a restless night I've decided not to do the design time thing. Two reasons:
1. Every application class would need to support an additional constructor.
2. There is a one-to-many relationship between element types and element instances.

So instead we're going with configuration classes which will embrace [most of] the parameters of an element type definition. This can be implemented incrementally as well, which is important at this point.

design time

Today I was working on configuration. Configuration is never easy, but in the Element Model it seemed extra difficult because it is spread across too many classes. Finally decided to make use of the JavaBean design time idea. Application logic should support its configuration.

So obvious. Not even original. But I think it will help a lot.

element model release 10.0.0, goals for 11

New validate utility checks the integrity of a database.
Additional convenience methods added to AbstractApplication.
Javadoc rewritten for the elementmodel package.

This completes basic persistence. For release 11 there are 3 objectives:
- Employ weak references (in handles) and a cache to reduce the memory footprint.
- Use variable-length blocks in place of fixed-length blocks.
- Extend browse to the point where it operates as a simple wiki.

A light-weight EJB replacement

The Element model has come a long way and release 9-11 is out.

• Peer Proxies are complete.
• Basic persistence is done.
• Dump/Load commands can be used to migrate data from one release to the next.
• Naji has started work on integration with Jetty.

Download

The Rolonic Framework is now Complete

http://agilewiki.wiki.sourceforge.net/

Release 8-0 of the element model completes the Rolonic framework. The next step will be to add Peer Ark Proxies.

element model framework now supports toolbars

Release 5-3:

New setHeadline command.
[up] and [home] have been added to the toolbar of GBrowse.
The framework now supports toolbars.

Contributors to this release: Bill, Naji.

element model 5-2

Fixed a critical bug introduced in 5-1 which prevented most sample programs from running.

Added configuration support for headlines.

ToolTipText is now based on the element's headline.

element model release 5-1

http://agilewiki.wiki.sourceforge.net/GFrameManager
http://agilewiki.wiki.sourceforge.net/ExitOptionOperation

Release 5-1 is out. The focus this time was on cleaning up the frame management classes--which have now been reduced to just GFrameManager.

Also, catch the two new wiki pages above.

element model release 5-0

The element model now supports the development of fully decoupled Swing components. Layout can now be separated from behavior, making for a much more fluid architecture.

Added a new page on Swing, too.

element model release 4-9

RsBrowse is replaced by GBrowse.
The old rswing package is gone.

The new GBrowse program uses BoxLayout in place of GridLayout and behaves better.

element model release 4-7

New samples package.
ArkLocks are no longer reentrant.
Configuration of multiple top-level rolons is now supported.
New getCompoundPathname for navigating multiple arks.
Responses are now returned using the new ROUTE operation.
A contextMap is now used with commands and route operations.

I'll note that by using the route operation to return command responses, sockets will be fully bi-directional with no session tracking on the "server" side.

element model release 4-6

-New CommandStatusEvent for tracking command completion.
-[non-GUI] Browse now supports asynchronous commands.
-New swingcapabilities.CommandManager class supports command completion.

element model release 4-5

Any program can now be run using a generic Main.main.
A new integration with Swing is included.
ThreadPool is now part of ArkRoot for reduced locking overhead and greater flexibility.

element model release 4-4

o New up and destroy commands.
o The sleep command now demonstrates an asynchronous response.
o A thread pool is now used in place of dedicated threads.
o Command API now includes a pathname of the target.
o All commands rewritten for improved thread safety.