About Technologies

People keep asking about what technologies gallery uses, so I should probably answer.

Ultimately you shouldn't be able to tell (although for now there are still a few bits of the architecture which poke out from underneath, normally when I get something wrong).

The short version is Apache running on a Linux box, built to a passable spec in 1999, talking to a PostgreSQL database. We've just upgraded to version 7.1 - which means I'm still all elated about how damn fast it is. So elated, in fact, that I haven't rewritten the queries to use some of the fun features too. This means two things, first that things will get even quicker yet, and I'll be adding some of the funky features that are part of the constant development of the place. A big hand to Tom^[TC] for getting it all together.

Most of the code is written in PHP, although much of the interesting logic is actually a bunch of regular expressions driving Apache's mod_rewrite module. This is the bit that makes all the addresses pleasant and friendly. The part I'm happiest with is keeping search URLs pleasant.

gallery is also bringing together the elements of a sensible, understandable, useful & open source community toolkit for people building sites which want notions of users, comments, collaborative organisation and other things, to save others building these things again. Philosophically, it borrows a lot from early versions of the ArsDigita Community System, back when it was written in a noddy scripting language (in that case Tcl), rather than as a buzzword-compliant (J2EE et al) tool which fits a very different niche.

This toolkit lets people build sites where:

• A number of related sites may share a common sign-on procedure
• You get basic community features for little effort, for example user-accounts and in-page comments at the bottom of any page
• You can build a reasonable site, from the ground up in an hour or two once you know a bit about how things work.
• You can build whizzy interfaces to let ordinary folk get a lot done without deep knowledge of how the whole kit works, just how to call it.
• You can contribute code back to a relatively simple core.
• You can easily share a single installation between a number of developers using the same deployment environment - after all hosting a bazillion & one virtual sites is what Apache does well. Those sites may need local variation in the toolkit, which is pretty simple.
• Different sites may or may not share a common database, irrespective of whether they are running from the same core.
• The kit in general supports doing things well - so you should get clean URIs, sensible navigation, accessibility & compatibility as simply as possible. We're building the tools to help you do this.

The last point is probably the most interesting, and the tools that are presently envisaged include:

• A tool to keep URIs clean. At present we - by choice - use Apache's mod_rewrite. But it is really voodoo. People should be able to map variables they wish to pass into the path of the URL without much bother. Our funky site-map thing is for just this problem.
• Producing valid markup isn't too hard - but gets much harder as documents start to live and breathe on their own. That is, when you have really dynamically generated pages - with newsfeeds from elsewhere, content contributed by users, content that depends on the permissions the visitor has &c - you really need to validate each instance of a page not just the odd noddy example. We have a couple of schemes (and almost enough time to code them) to make this happen quietly in the background.
• The above extends almost immediately to valid output of a number of forms. There's no reason you shouldn't do spell checking the same way - and alert the people responsible appropriately (and let them assert that "no it's fine, really" as well). You could even do a module to try and spot patterns of grammar which you know you use, but don't like. This is likely best done for your own style of writing, otherwise there's just some code-monkey somewhere deciding to
  scribble on people's personal style in green ink
  . A warning to Rob Chatley^[Rob], ash will probably try and talk you into doing stuff like this, since you've mentioned it over beer in Finnies.

Just so that no-one gets confused, and for complete clarity & disclosure I should say that I - Ashok^[ash] - was previously employed by ArsDigita. I wrote the initial version of the code here in my spare time while working in the London office - where I was employee number 3, starting as an intern while studying for my degree. When I graduated I carried on full-time, and learnt a lot from the smart people who were at aD at the time.

What I do and say here is my own opinion does not necessarily represent what anyone else thinks - it was never aD's. It does represent a slice of what Future i thinks, since I'm one of a bunch of folk who have got together because we're more effective in one another's company - literally.

If you want to know what I really think of fancy, buzzword-compliant kits like the latter-day ACS, you should talk to me over a pint.

This is just for those folk who might get all confused as to what hat I'm wearing when I do this site. This is my baby, with the advice and help of a bunch of clever friends through Future i, to explore how we can best use the Web. If you can't cope with that - hey-ho.