mca blog

i've been working through the details of what it will take to get exyus through to a full release 1.0 state. and the remainders are not too bad.

currently, things are at 0.7. this includes solid support for file-based, and SQL-based storage (via MSSQL). it also includes solid support for all text-based media types (HTML, XML, JSON, ATOM, SVG, etc.). basic web caching is in place (local to the web server memory) as is caching of internal state and template data. the URI routing is also solid (using RegEx for mapping w/ internal reflection as storage for the routes->object maps). support for basic and digest auth is also fully supported as is compression (gzip,deflate).

this all results in a solid web app environment for single-server (or web server + data server) situations. but there are a few items still needed for really scaling up and out.

security

first, the security setup (users+URI+methods) is stored in XML files (auth-users.xml and auth-urls.xml). this needs to move into the database. that will not only allow for better scaling, it will also make it easier to build and manage users and auth points at runtime. updating the security system is a .X release in itself.

another issue is that the current server does not support form-based authentication (via cookies). this is proly good, but may not fly for public apps. ideally, i need a solution that handles http auth (basic/digest) as a form-based model. that way, i only need to engineer the form-handling and leave the rest alone. not sure how to handle this one and it might wait for 1.1 or later.

caching

next is scalability. the model needs the ability to operate in a multi-server (farm) environment. while the current web page is stateless (no session dependence) and, therefore, supports a multi-server setup, the caching implementation is currently tied to a single server. this needs to move to an out-of-bad (remote) model. using memcached would be a solid way to handle this. another aspect of the caching model is currently dependent on running an HTTP client on a separate thread to handle cache invalidations on update. this, too, needs to move to an out-of-band process. so a remoted client that listens to queued messages will also be needed. while this update is not required for a fully functional server, it needs to be considered early on. it might need to wait for 1.1, tho.

xinclude accept bug

the library i am using to implement XML/XSLT has a bug in it's suport for the accept and accept-language attributes for XInclude. there is a work-around, but it's a pian (using URL arguments instead). this should be fixed before 1.0 is done.

binary support

currently, the framework only focuses on text-based mime types. binaries (images, PDF, etc.) are not supported - except through direct file responses. it's not a big deal, but i think PDF would be a very valuable inclusion for the framework. again, this might wait until after 1.0, but maybe not.

the upcoming releases

i expect 0.8 to cover the security item. 0.9 will be a final clean up of any problems and shake out of new stuff. this is where the XInclude can be fixed and possibly the form-based auth, too. that would be, imho, a solid 1.0 version ready for full release and production use.