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/