The people Coding standards Design Rewrite rule TODO DONE Sun Java
Javadocs Class Hierarchy Index NAWS MTRX security servlets Skang Squeal & Stuff zen developer
Stuff that has already been written. It may not be perfect, but it is considered a close aproximation of the finished product.
The very first part of matrix-DFS ever written, handy that it comes first B-). This is the login client. The current version is specific to Telstra BigPond Cable (AKA BigPond Advance). The "NO" stands for Network Organiser. Currently on hold, see moved.shtml for details.
ANT is used to build everything. No link to build.xml is provided, as browsers are likely to not know how to show it. Skang knows how to build everything by invoking ANT. On a sucessful build, the currently running Skang application will automatically shutdown and then start the newly rebuilt version.
Part of build.xml (the ANT build file). The distributer will ensure that everything that needs to be generated is generated, fiddle with line endings, pack it all up into a zip file, move the zip file into a matrix-DFS servable location, and do a test install into the ../TEST directory.
You are reading the documentation. See source code.
This is the only servlet that needs to be served by the servlet engine. It makes any Skang module a servlet, completely transparently.
The center of it all, see the Skang documentation.
The AWT skang extension.
Every Skang extension has one of these automatically generated by the Builder, using a Java 1.4 doclet. The long winded name is needed to avoid the Builders "clean" target.
Lots of source code has been written, and even more needs to be written. Mentioned here because Zen editor and Zen painter are both used to produce source code, although Zen painter only creates skang files.
A Skang extension that wraps around JDBC SQL stuff. We also need a generic SQL editor / manager front end.
A base Thing for accessing table type data.
Even more central than Skang, everything that is managed by Skang is represented by a Thing.
The level of computer knowledge the user has. While this has been defined, it needs to be used in places other than the developer popup.
A digital Watch.
A Jabber based chat client. Currently on hold, see moved.shtml for details.
The main window of the Zen developer.
Stuff that has only been prototyped, or partly written. There is some code, and it may even work, but it is not even close to the finished product.
This will update a DDNS server when the users IP changes. Burt Alexanders IPScan is the protoype, but it has been shifted to the historical section until we are ready for it.
BPC_NO has a debugging system that tracks method calls. Something similar should be generalized and built into Skang.
This represents the files that a user may download (or upload even). net/matrix_rad/matrix/Matrix.java has a simple download widget to represent this.
The little cartoon of onefang in the corner. He goes through a range of emotions to represent the general health of the application.
Checks the overall health of the network. BPC_NO has a prototype which needs to be copied out, generalised, and extended. NOTE - the BPC_NO prototype should be left alone, only make changes to a copy.
Provides both status line help, and context sensative help pages. Both are generated by the Skanglet doclet. Well, the status lines are, the pages are not done yet.
The bit that does all the work is part of the Builder build.xml script. We
need a GUI, and some OS specific stuff.
There is currently a copyright widget that cycles through copyright messages generated from information embedded in Skang modules. We should extend that to non Skang classes. Clicking on it should display the license for the class currently displayed.
Represents chat messages. Currently this function is supplied by Jabberbeans, but that has major problems, and we should write our own.
See the link for details. Grid and Tree have been borrowed from HSQLDB, and extensively modified. Popup is from a very ancient project, but with very little change. Throbber is described later. All of these require major changes to turn them into NAWS. Scrolly was written for two reasons, one is to be the base text thing for NAWS.
Security is being retro fitted.
So far, TeenyWeb is a very basic HTTP 1.0 server. The actual protocol part has been split of into a seperate class, leaving TeenyWeb as a brain dead inet style thing that only supports a single port.
While nothing has been written yet, SkangAWT could be easliy modified to do this.
Currently living in net/matrix_rad/skang/What.java, this should grow into a proper status
system.
BotLabLeft and BotLabRight should be split off into a status line module,
keeping both, left typically for output, right typically for errors, or left for
headings, right for details. Coz so much stuff needs to talk to status lines,
there should be a concept of "time to live" for each message sent to the status
lines, with the currently alive messages available via the tooltip, and probably
a drop down of some sort. A default TTL of one to ten minutes should be
adequate. Messages should also have a priority, with higher priority messages
closer to the top of the display. The status lines themselves will loop through
displaying the currently alive messages in priority order, with very high
priority messages flashing on a red background, maybe with lesser display antics
for not quite so high priorities. A higher default TTL for higher priority
messages off course.
We need a method of sending status across the net to a running Skang applet.
NOTE : the current output redirecting trick doesn't always work for applets.
In the Zen developer there is a method that prints out various values to help with portability testing, in response to the "check" command. This should be generalised. Automated testing methods of the system itslef, for development purposes, should also be added.
This is just a looped animation at the moment, with configurable graphics. It should become the output widget for the network health checker.
While the TeenyWeb protocol handler and the Matrix.java download widget could be considered extremely basic HTTP protocol handlers, we need to write real ones. Then write transport handlers for more protocols, FTP, TFTP, HTTP 1.1, WEBDAV, and subversion at least.
Zen developer will invoke jedit when run as an application, and a TextArea in a Pane when run as an applet. The TextArea needs to have some functionality transplanted from jedit. Then we can do the instant compile thing.
Stuff that has not been written.
Wrapping SkangNAWS windows around 3D objects. Navigating a 3D world.
Alpha blended GUI.
A file browser that understands extended MIME and matrix-DFS transports.
Auto config shifters for apache, wuftpd, and other popular servers. To make a one button server install that people can use to replace / augment their current legacy servers. If we make it as easy as possible, more people will use it.
On systems running BPC_NO, the major point of failure is now the
DHCP client in use, so I intended to write a Java DHCP client that would be as
robust as BPC_NO. DHCP uses UDP on the broadcast addresses, so a Java DHCP
client is feasable. Remembering that some non-windows DHCP clients had trouble
with BPC's DHCP server, keep an eye out for microsoftness in DHCP servers.
Actually changing the OS's idea of it's IP address has to be done via OS specific
JNI.
RMI? Corba? Extended servlets? Maybe just a modular wrapper around them all?
Skang modules can now run as servlets, so we have made a start.
Filter out spam, virri, banner ads, porn popup windows, and other nasties. Try to filter at the server whenever possible to keep bandwidth down.
Port Linux "IP tables", or whatever it is this year to other OS's, and write skang modules to configure it.
Modular IDS, with wrappers around the good open source ones. Translate the really good ones to Skang / Java / JNI.
Skang needs an intelligent layout engine that can layout a widget relative to
other widgets. It should be able to be handed a list of widgets & sizes and make
a first pass at laying them out. For database work, for instance, it would just
read the details of the database fields from the database itself and not need
any more info. The same thing applies to USAGE details, they represent the
parameters that a user may want to edit for a particular module, so we should
scan through USAGE and autogenerate configuration skins.
"Mandala generators" display the results of Zen contemplation to the user. The basic one will gently float multiple tooltips randomly around the center of contemplation (editor cursor position), with the background of the tooltips slowly colour cycling through pleasant pastel shades.
The user interface to Zen contemplation is controlled by "Mantra" modules, the basic one is just a button labelled "Recite mantra", a more complex one can be voice recognition of particular mantras being recited by the programmer. Lazy programmers can have an audio clip in a loop of themselves reciting their mantra. Really lazy programmers can use an audio clip of someone else reciting mantras.
As a general principal, it should get more specific the further to the right we get, so OS version must be rightmost. So now we have VERB/TYPE/SUB-TYPE/OS. "Transport" will be a new TYPE. Anything with just two parts is assumed to be TYPE/SUB-TYPE to be backwards compatible. Anything with just three is assumed to be VERB/TYPE/SUB-TYPE, that being the most common case. All four would only be used to search for a specific module for a specific OS.
Watch needs to have NTP code added to it so that it can syncronise with the world's atomic clocks. It should keep synced time independantly from the OS, and have an option to sync the OS. Keeping track of drift should happen as well.
NTP server code with an auto load balancing thingie needs to be included. When I created the BPC NTP network, the biggest problem I solved manually was determining which of our servers asked for the time from which of the worlds servers. Load balancing was not the only criteria.
Used for encrypted connections, and code signing, instead of expensive CA's.
A small group of servers that goes of in search of the cause of major network problems. May also go in search of hard to find modules. The general idea is to keep the network load down by preventing every client from doing the searching.
Local proxy to allow legacy browsers to talk to matrix-DFS servers. Also serves help pages.
Searches for modules that implement extended MIME types.
TeenyWeb can be extended with a servlet engine, where the servlets can be skang modules. OR maybe they can only be skang modules?
Generic "distributed computing" hooks.
The bit that takes care of transferring a file from two servers at once.
"Tao generators" help find the way, they are the Zen contemplation modules that
search for relevant text and code snippets. They desposit the found bits into
a central database. The "Genetic Tao generator" gene splices code snippets
from this database. The "Travesty Tao generator" creates output based on
statistically based randomisation of the database. The "Javadoc Tao generator"
searchs Javadocs for relevant API documentation to drop into the database. The
"Google Tao generator" creates random three word search terms, and uses Googles
"Feeling lucky" searcher to find things to drop into the database.
You get the idea.
Tokenises text based wire protocols. Now called the Transmogrifier.
Generic trust metrics for any part of the system that requires it. Some examples are - censorship, code signing, connection encryption.
A skin editor needs to be written, along the lines of the one I wrote for
MicroKnox. The MicroKnox one is an in house tool that is not open source, so no
one will ever see it. The trick is to have the skin editor popup from the
running app (an "Edit this skin" option on the develpoers menu). After the
editor goes away, the skin reloads and we have instant skin editing feedback.
The running skin becomes the editable skin canvas, no point opening another
window since the skin is already displayed on the screen. This option should be
available to users as well to customize skins. The editor should have two
windows, a widget pallette and a current widget parameters window, with the
parameters window filled according to what type of widget it is.
Stuff that has been written by others, and will continue to be written by others.
Freenet provides some of the intelligence that we need for doing virtual server stuff. They are building from the ground up, we are building from the stratosphere down. We should be able to meet somewhere in the middle. In particular, add extended MIME, GUI, and the assorted URN RFC's.
Via the local proxy, we are able to support legacy browsers. Skang modules should also run as applets in legacy browsers.
We want to provide an upgrade path for these. Writing matrix-DFS protocol modules and automatic config shifters ought to do it.
We use JDBC drivers to talk to a variety of databases. See "Squeal".
This file was last modified on Friday, 12-Nov-2004 10:09:53 EST