I didn't get any coding done over the holiday weekend on the new project, though I did make some progress deciding what needs to be coded. That's probably a good thing. That is unless it is an indicator of insurmountable inertia.
My first problem was a little sad. I couldn't pick the codenames for the project. You'd be surprised how something like that can get inside your head and slow you down. Of course it was just an excuse to procrastinate and enjoy a few days away from the computer, but I really did have a hard time deciding on the names. In the end I decided on... well, you can figure it out.
I spent some time looking for the right toolkit for the server side of the application. What I want is a good component architecture -- something that enforces a separation of concerns and an inversion of control. But not much more than that. I really just want a couple of classes on which I can hang my own components. I checked out AxKit, PageKit, Embperl, Mason, etc., etc. They are all great in their own ways, and more power to them. But sometimes all you want is a good component factory -- one that can simply call lifecycle methods, and maybe give you reasonable pooling capabilities. (If this sounds a bit like Jakarta's Avalon, that is because I have definitely been influenced by their thinking.) I'd like to be able to plug in a templating system, rather than have the execution be driven by that system. For instance, I've flipped JSP on its head so many times (so that servlets push finished data in to JSPs, rather than the normal approach of JSPs making call-backs back out) that I wonder why people don't just design these frameworks that way in the first place.
So as it is, I'm going to write a bit of this basic component management functionality -- and I will keep it simple -- as part of the Essex subproject. If I do things right it won't be more than a dozen classes. Just enough to instantiate simple components and manage their lifecycles. All of the rest of the application stack -- from the mod_perl handlers to the template system to the request dispatcher to the database interface -- will be managed components. I'm not going to go overboard with this. It's neither the time nor place for that. And having written code to do this sort of thing a few times in the past, I'd like to focus on something new this time around. Oh, and Essex is not a framework. It's not a foundation. It's not a platform. If you want to call it anything, call it a lightweight component factory. Or don't call it anything -- just ignore it, because that's what I hope to do.
(This is a good time for someone to interject with a recommendation of some code that already does this without a lot of additional overhead.)
The second task will be writing the server application logic itself. This part, codenamed Orchard, will provide the web service APIs that the client applications are built on top of. It will consist of a specific implentation of a request dispatcher, which may need to be a little clever to handle the REST URLs, a layer that can manage authentication protocols so the handlers don't have to worry about them, our data access/persistence layer, and each of the individual request handlers. This can be as hard as one wants it to be, so to limit the scope a bit I'll focus first on just inviting new users, managing passwords, and setting simple preferences. Then I'll add the support for groups -- creating groups, adding and deleting people from groups, etc. Then, since what I discussed in part 9 is so interesting to me, I'll work on getting users and groups to work across multiple servers. Then probably a bit on the discovery and search of users and groups. Then finally on to creating and managing content, such as notes, and tying those in to the user and group model.
I'd like to cover ground quickly without trying to get everything perfect the first time. While this may make things harder on anyone trying to use the APIs as they are being developed, I'm not going to get it right in a vacuum anyway, so it makes sense to roughly sketch as much as I can and enlist other people to help me see what needs refinement.
The other roadblock that caught me off guard this weekend -- I did intend to write a little code if I could -- was a lack of a development machine. I do everything non-job-related on my PowerBook these days. That works great for writing text, day to day email, or simple code like AWS OpenSearch, but it's not ideal for a bigger project like this. For one, just getting the requirements (Apache, mod_perl, MySQL, etc) on Mac OS X is a new challenge. It's not impossible -- I'm sure it can be done -- but it is different than my standard Linux development environment. So while the unto.net server is all ready to run the code, writing it there via a ssh connection over the Internet isn't nearly as effective as running emacs on X via localhost on a fast development machine. (And while I do happen to have nice Linux hardware available, it's for work, and I'm still keeping all of this physically and mentally independent from anything work related.) I may need to set up a Linux workstation for this project, but since I'm out of desk space, I'm at a bit of a loss.
I'm sure this all sounds awfully dull, but I suppose software development has those moments, so I may as well be transparent about the slow parts as well as the fun parts. For anyone who wants to think hard, I'd love it if you read through part 9 again and could pick apart the security flaws before they come back to haunt the project.
Oh, and even with all of the great suggestions people made in the comments of part 10, I think I'm going to wait a while before setting up a real CMS or a forum system or, ack, a bug tracking system. It's not that those things aren't important -- it's just that getting bug reports at this point in time would make this project feel like work, rather than something I'm doing because I genuinely think it's fun. Someday, of course. But not today.