For those of you that are interested, Webflex is now feature complete for Version 1.0. This means I no longer have any completely new bits to add to Webflex (I think). Instead I now have the tediously boring task of reviewing the 1000s of lines of code I've written and make sure it's mostly consistent (which I know it isn't) and test that it all works (which some of it probably doesn't).
What is Webflex?
If you have no idea what Webflex is, then let me explain. About three years ago I was registering on various forums, noticing that each time I was repeatedly putting in the same information. This got me thinking that rather than using a web browser to access a forum, one could craft an application that would be able to access forums in a similar matter, but allow extra features like automatically registering at new forums and keeping those profiles in sync. This idea grew into Aspex, which is currently on hold. As I was writing Aspex, I noticed two distinct streams in the project: one side dealt with the forum part - headers, boards, posts, etc. and the other side dealt with managing data and the website. I noticed that there was a clear gap between the two streams, which allowed me to to focus on creating a basic website management tool, which could be easily extended to provide both a web-based and local client based interface.
This web and local client mix is where I believe that computing should be heading. The browser is nothing more than an over-hyped shop window. I'm not going to use a browser to edit my 100,000 word thesis, I'm not going to use a browser to edit my companies balance sheet and I'm not going to use a browser to create and show a presentation; I will use desktop applications for these tasks. I'm going to use a browser to read articles, and access the communication services that networking (not just HTTP over TCP) allows when I'm away from my normal computing context (like at an airport, in town, etc.). These communication services could be email, facebook, twitter, etc. If I'm going to use these communication services they need to integrate into my current computing environment, and if that's isolated in a web browser, then that's one more button to click which is one more barrier to cross. Therefore, any communication service worth my time will have both a web based interface and a local client that can integrate into my operating system (such as a Twitter gadget for the sidebar to let me micro-blog my current activity).
Anyway, back to Webflex. Webflex itself looks after the management of a website and it's data. The idea is that you take Webflex and build up your website around it as one or a number of plugins. Plugins have two versions: a server and a client version. The server version contains Data Item classes, Data Handler classes, Web Services, Web Pages, plus the necessary XML and code to install the tables into the database. The client version contains the web service clients, controls and other classes to integrate with the Webflex client and allow users to access the services on the server.
The way in which Webflex manages data is quite important. I felt that it was important that Webflex is as compatible as possible with different DBMSs. Unfortunately DBMSs have different ways of expressing similar (but subtly different) things, so I needed a way to express the tables and queries that would be used in an independent way, that was easily usable by my code. This resulted in the creation of XTDML (eXtensible Table Definition Markup Language) and XQDML (as XTDML, but with Query instead of Table). These two XML based formats describe the necessary features of a table and query in a way that allows them to be converted to SQL statements at runtime to be installed into a database. Rather than executing SQL queries each time, XQDML files are saved as stored procedures and views on a DBMS, so only the very simple task of calling the appropriate stored procedure is needed to get the data. I also wrote a tool to convert Access queries to XQDML meaning that a developer never actually needs to touch SQL when developing a Webflex application. Unfortunately the side affect of this is that Webflex is incompatible with OLEDB and ODBC databases (the .net provider for each doesn't support named parameters) and MySQL 4.0 and below (it doesn't support stored procedures or views).
Another major feature of Webflex is it's security model. The core of Webflex consists of about 15 tables for storing users, groups, plugin and security data. Each user can be a member of many groups, upon which security controls are applied. When a plugin is installed it may register a number of Object Types that can be secured. Security can either be shared among all records in a table, or specific to an individual record. The plugin will also specify the default security for each of the five ranks for each action defined on an object, so for example a plugin could specify that by default an Administrator can Edit a Header, but an unregistered user cannot. This model allows for the adding of any number of objects and any number of actions, helping Webflex be a highly extensible core for a website.
The final feature of Webflex is the Task Manager. The Task Manager has a number of Tasks, that contain a number of actions and a number of triggers. Triggers can be triggered by an Event, or at a certain time (which can be repeated over a certain period). Whenever a trigger is triggered, each of the actions associated with that Task are run asynchronously. Examples of Tasks include Installing a Plugin when requested, or sending an email to a newly registered user.
And that pretty much sums up what I've been working on for the past three years. And in writing this I've just realised that I haven't yet written the web interface, the ability for the local client to add new tasks to the Task Manager or for emails to be sent to new users telling them their credentials and registration code. Oops.