Code is a lot more than just implementation. It embodies ideas and techniques. And sometimes that code is self-contained and has broad utility. So why not highlight the more interesting code?
Anything that gets more eyeballs on the code is a good thing.
The problem with XML is that each document must be of fixed length. So you can't use XML to represent a stream of data. Worse, XML parsers often do not allow data after the end of the XML document, so you can't just append one document after another.
To represent a stream of XML documents, I first used zip streams. Fine except for the extra overhead and the limit of 64K entries. Then I realized I could just use a control character to separate the documents and implement a reasonably small Reader class to keep the XML parser happy.
The singular achievement is a representation for user objects, which we call Rolons. These are very fluid, high-level objects capable of holding any content and implementing any service. Indeed, the database itself is implemented entirely from Rolons.
Rolons are simple structures which can be expressed as an XML document. But they are also fully scalable. Case in point, the Ark Rolon tracks all available disk space and the location on disk of all other Rolons. So unlike a regular OODBMS, objects can easily implement huge indexes to very large numbers of other Rolons. B-trees are used, as needed, in the implementation of a Rolon. Access is fast, regardless of the size of the Rolon.
As fluid structures, a Rolon can participate in any number of applications. This makes building suites of integrated applications a snap. Qualifiers and Relations, which are specialized Rolons, are used to interconnect Rolons while directly supporting a wide range of possible queries and with good speed.
User profiles, user groups and access permissions allow fine-grained access control of Rolons. User groups and access permissions are implemented directly as qualifiers and relations, providing enormous flexibility with little overhead. The JSP code used to implement the management interface for these is itself the first application.
Now with user objects, qualifiers, relations and access control already implemented, applications then can focus on just the business logic and the user interface. And with everything running under a single JVM, it is easy to install and runs fast.
I am delighted to learn about Wagn, were everything is a card. That's a nice parallel to "everything is a Rolon." Wagn's cards are a simplified implementation of a Rolon, all be it with a more mature UI.
I suggest we add the card view to AgileWiki--making it the default view. This will support the creation of much nicer web pages with a higher density of content.
Release 15.11.0 of AgileWiki is now running at agilewiki.org. This is the same Com11105 program included in the download with a few tweaks made to the Jetty configuration:
1. It uses port 80 instead of port 8080.
2. It serves up a different web page when accessed via rolonics.org or rolonics.com.
But the demo still listens to port 11105, so if you run the Browse11102 program you can open a PeerArkProxy to it just by specifying a host of agilewiki.org and a port of 11105. This gives you a lot of additional capability, as Browse is much more mature than the web interface. Only it is not as user-friendly.