— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
Once you've become familiar with what there is (btw: a quick start guide is in review), probably nothing tells you more about what you can expect in the near future than the project issues list. The Issues Tracker at http://hll.dev.java.net, the project hosting site, currently has 11 issues logged. There are some that I do not believe will be particularly difficult to take care of, and at the same time will greatly benefit application developers. Issue #1 is a good example. XML Based Plans is critical to bringing the manager's role to what it minimally should be. FIPA compliance is quite simple, and then I'll want to apply it, even within the HLL Core (and it also makes for better applications). Rule-processing can be added by using an existing open-source package, but I'd also like to have a simple one specifically owned by and adapted to HLL.
Here's the list with short descriptions:
1. Configuration Files and Processing
Configuration files are quite important to the HLL architecture. In fact, I'd go so far as to say there should be applications built by configuring them rather than always writing new Java code for new application components. Applications should even be able to reconfigure on the fly, allowing them to add new capabilities or modify their processes and plans.
Although I've written code that handles configuration files in a pretty generic manner, I tended to define configuration files one at a time during prototype development as the need arose. The really crumby thing is that the HLL Core code explicitly looks for a particular set of configuration files on start-up. That means, that I'm carrying around a configuration file for the robot demonstration, for example, unless I change the source code so HLL doesn't look for it. That must change; and what I have planned is a master config file that tells HLL what the other config files are; and a flexible enough read and storage process to allow application developers to define their own configuration files.
2. FIPA Compliance
FIPA stands for Foundation for Intelligent Physical Agents and the FIPA organization has put forth a standard for agent messages, available here. If you thought much about the subject, a lot about it will just seem like common sense. The parts of a message include who sent it, where it's supposed to go, and other information allowing tracking of agent processing (and a message of course). The FIPA standard is well thought through and compliance provides the added advantage of facilitating communication with other agent systems.
This seems like a rather easy one at present. I just need to extend the current message object and assure that the elements are named according to the standard. The current version of the code is still small enough that necessary changes to the Java code that processes messages won't take long. Now is the time to do it.
3. Simple JSR-94 Rule Processor
There are a number of places in which rule-processing can increase the power of HLL significantly and simplify application building. The prototype uses server protocols to define the behavior of actors. Server protocols are not difficult to master. Just in case you've never written one, they tend to have if-then statements that direct processing when a message comes in to a server. A nice rule-processing system could turn this part of application building into tool-driven process. Alternatively, an open-source package like JBoss Rules (formerly DROOLS) would add a great deal of power with what is a powerful and straight-forward construction process.
But I'd still like to have at least a simple rule-processor that belongs to HLL. Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).
4. XML Based Plans
At present, an HLL manager can use resources. Resources in the form of java objects can contain plans, written in java. I want to bring at least part of this process out of coding and into XML files so that plans are easily configurable without changing source code. Note, this can also lead to an easy way of adding and modifying plans on the fly.
Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).
5. Code Review
All project members are invited to review all the source code.
6. Logging
In the prototype, most error handling consists of printing error messages to the console. When the GUI interface is involved, there is some logging supported by Tomcat. We need a better logging system.
7. HLL Server Protocol Modification
The initial issue was that the HLL Core server called an application specific protocol; which means that the Core server needed to be modified for each application. There's been a simple work-around; requiring a generically named server protocol at the top of the application's process: HLLServerThread class. I would prefer to replace that requirement with specification of the application's head server protocol named in a configuration file.
Work on this should probably follow work on configuration file processing, since rule bases will likely be expressed in XML (same as configuration files).
8. GUI Always Initialized
If I now tell you this has something to do with processing configuration files, you should be getting the message that configuration files are important.
9. Multicasting to browsers as option
Readers of this blog already know that I implemented Multicasting to browsers before changing to a URLConnection. Since I've already done it, this issue is assigned to me. I only need to hook it back up again, and (you may have guessed) handle whether it's used or not in configuration files.
10. General Browser GUI Issues List
This is where I'm listing issues for improving the GUI.
11. Security
Eventually, the HLL executive will need to start checking to see if messages received from the outside world come from an authorized source, and even handle encryption for some applications.
This comment has been removed by a blog administrator.
ReplyDelete