For a document repository, does it make more sense to:

1.) Tie metadata to a given document
2.) Have a central directory for metadata that is independent of the document collection

A decent UI will more or less abstract that issue away from the user, of course, but I'm concerned about design issues. The repo is atomic, and it's not difficult to query, so I see the issues as kinda breaking down like this:

2.) is easier to manage at the collections level (duh), and assets such as binary files can be introduced into the system without having to create metadata documents to accompany them, however a risk of collisions within the metadata index exists, since changes to different documents can trigger changes to the same metadata file.
1.) is arguably less manageable, but no significant risk of collisions. Also, #1 makes it easier to index documents with something like solr -- although updates across the repo & solr and *not* atomic, so there exists a risk of the index getting out of sync with the collection.

There exists a third option: have the metadata dir that shadows the document dir. This more or less eliminates the risk of collisions, but... well, I'm not sure what the point would be, honestly.

The other day, I had a few minutes to kill at a friend's place. I decided to spend it working on boomstick, when I realized -- to my horror! -- that they didn't have an ssh client on their machine. The solution? To add a java ssh client to boomstick.

With proper configuration, MindTerm is actually shockingly decent, and it's painless to install (well, so long as you only want to be able to ssh into the machine hosting the applet.) The license, however, is problematic. It's actually quite reasonable in many ways -- you can rummage through the source, use it free for personal use, even use it for free commercially for less than 25 users -- but it's restrictive enough that I doubt I can (or would want to) integrate it with an open source project... which means I'll have to strip it out of boomstick when I finally get around to releasing the source. That's not difficult at all, I mean it consists of a single jar file and a page with an < applet > block, but it would be cool to be able to distribute a cms with its own ssh client. I mean, c'mon, that's just cool. Cool, and not to be. Ah, well.

Progress on boomstick. It now has some basic site layout and tagging functionality. Everything can be painlessly managed from svn. It is functionally adequate for managing static websites. Next I need to build an interface to update svn from cocoon, implement the search function, gel the repo structure, and do some simple stress testing. Slowly but surely it bootstraps itself.

If anyone has any ideas for website functionality (including blogs, wikis, whatever), client or server side, feel free to throw them at me. Depending on a bunch of things, I might implement them. Since I'm apparently reinventing the wheel for the eight millionth time, I might as well try to do something interesting with it.

Progress on a work project that is keen, but that I won't go into here at the moment. Found some weird bug with google maps and how it handles coordinates. Apparently I'm the only person on earth with this problem, so I'm sure it's simply the expression of some other bug in my code somewhere. Magical.

It is late and I am weird. There are suddenly hints of old states of mind. I am tired. I am going to bed.

Man, I am lusting after XHTML 2.0.

http://en.wikipedia.org/wiki/XHTML_2.0#The_XHTML_2.0_draft_specification
http://www.xml.com/pub/a/2002/08/07/deviant.html
http://www-128.ibm.com/developerworks/xml/library/x-futhtml1/
http://www-128.ibm.com/developerworks/xml/library/x-futhtml2.html

And, of course, the working draft:

http://www.w3.org/TR/xhtml2/

Okay, I'm not quite *lusting* after it, but it looks cool. I'm all about streamlining html, offloading presentation to css, improving the quality of semantic markup (particularly in structuring document hierarchy), and legitimizing common scripting techniques (rollovers, dropdown menus, form validation, etc.) by accomodating them in standards.

Progress on boomstick. I hooked the repo up to a version of cocoon that I modified to use saxon instead of xalan. Performance is comparable to xalan, but it allows me to use XSLT 2.0, which is nice (grouping, user-defined functions, no crap like RTFs and whatnot.) More importantly, it gives me XPath 2.0 & XQuery, which means I can query repo documents for metadata, which I can use to manage permissions, generate nav menus, etc. And, being in a cocoon pipeline, it's trivial to add a sitewide layout. Granted, I still have to write all of that, but the amount of code *to* write is relatively minimal, since I'm taking advantage of existing functionality. It's still missing stuff like, you know, an editor, but svn allows me to manage all of that from my desktop anyway, so that's a pretty low priority. Also, it's strangely therapeutic to manage a blog from vi.

This is a weird project. I've spent almost no time actually working on it, but a lot of time just kind of idly thinking about it. So far, though, that seems to be giving me a lot of leverage. It's entirely possible that the thing will turn out to be some kind of nightmare (particularly depending on how it scales) but so far, so good.