AgileWiki theory/tool outline

At first the terminology sounded a little crack-pot to me, but I'm less of that opinion after trying to follow-up on AgileWiki and "rolonic" theory. Of late the lead, Bill, has put out some videos explaining things, and I found What Makes AgileWiki Different? to be interesting - there's a dose of theory (rolonic, as they've termed it) which underlies it all, and the spirit is to make languages and development better, hence I thought it not totally inappropriate to mention it on LtU.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Comprehensive summary

Our current software stack has problems. That problem is that everthing looks like a nail when all you have is a hammer. You can do some stuff with relational databases. AgileWiki is a new tool in our toolbelt (if I'm right, it sounds like a leaf blower). It's based on "rolonics", which is a theory of something. Like object oriented programming from the 80s, it's a new way of thinking about things.

Be sure to ask about shipping and handling before you buy this thing.

yeah, i know what you mean

they are not doing a good job of making it not appear to be snake oil. i'm totally in the boat of assuming things like this are guilty until proven innocent as well. that was my first reaction for a while, and a little bit still is. however, i've since been trying to track down what they mean and are doing and the fog is slightly clearing hence i thought it worth posting.

sincere apologies if it is still way too far in the foggy most likely snake oil camp for everybody.

[edit: in case anybody isn't already turned off, here is a post which apparently tries to be a little more explanatory and which also indicates that the rolonic approach is kind of a hypercardy approach, to link it to well-known things. [edit2: the smell of it all to me is along the lines of the Qi4J stuff, that OO is okay but we need to do a better job of getting roles be first-class, rather than using static class relationship models.]]

Additional information

Additional info on this blog or on Wikipedia.

curse you

now i'm hungry.

AgileWiki Blog; and Rolons

AgileWiki Blog

You might find the references and articles there to be more lucid. Or you might not. A page on 'rolon basics' is available, and I will duplicate his 'headlines' bit here:

  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.

So, basically: users supply code (and initial data) in the form of XML of arbitrary schema (= arbitrary languages capable of inheriting from or composing one another, not a bad start), and system administrators supply Java plugins to interpret specific XML schema and possibly translate them into Rich Internet Applications (HTML, DOM, JavaScript, CSS, AJAX, Comet). This is all backed by a shared Wiki-like namespace (allowing new 'Rolons' to monkey-patch themselves into the existing collection and immediately begin registry and communications) and some form of persistence. I guess that by 'Web 3.0', LaForge refers to the ability for common users to extend the functionality of the services they share... a bit like Second Life, except with web-apps.

Resource Accounting and Functionality will certainly be at one another's throats in this model. Security will likely be weak, but that's normally the case in a Wiki. If my understanding is correct, there is no reason it couldn't work and be a reasonable step up from Wikis available today.

rewriting agile wiki

Agile Wiki is just too big. There's the versioning CoW database, the rolonic DOM, multi-server support, just in time serialization, a template engine, etc, etc, etc. So it is never finished and never good enough. :-(

So I'm starting over. I've got a nice implementation of actors which (like E?) can share an inbox/vat/reactor and which have extensions/facets and runs everything synchronously much of the time. Now I'm working on sequences and operations like filter, map, fold, head, tail, merge, intersection, etc.

The idea is to go slow, document things as I go, and make sure that when something is documented, it is usable. So it will always be finished. And likely stable, too, as I'm not changing the design that much.

See the wiki for more details.