Virtual domain mess sorted out. Auth system still needs to be built, but the auth framework is now working properly. I'm getting a better sense of how I want to handle ids and metadata. Issues remain, of course, but not stupid ankle-biting kind of crap. I feel positive towards the project again, and I feel like momentum has been re-established.

gYaAaAaAaH!!!!

I just realized that there's an enormous security hole in bs as it is initially sketched out. Since it can run multiple sites, and since those sites are not completely sandboxed from one another, and since it relies on filesystem access, it is conceivably possible that someone with control of one site could read data from another site running in the same instance of bs. They couldn't modify it, at least, but that's not good.

Or, rather, sort of. One of the premises behind boomstick is that a site is essentially divided into content, global content metadata, functionality, site metadata/configuration, and style (which is actually a subset of the prior, but is separated out for practical reasons). Obviously we could collapse all of that into "data" (with "rules" being a subset of "data") but that's a little more ambitious than what we are tackling here. BUT I DIGRESS.

Anyway, the point is that all of these things are part of a site and tend to evolve organically, and so therefore they should have a place within the cms and should be manageable within the context of the cms. What all of this means is that essentially everything that defines a site, except for a few java libraries and whatnot, lives within a repository. There are two points of access: a web ui for updating content (because that's what makes the most sense) and subversion for everything else (because that's what makes the most sense.) This split isn't perfect -- java libs, for example, still need to be maintained globally at the cms level -- but in practice it seems pretty good. Need to change a link color to blue? Need to insert google ads into the page layout? Need to write an mp3 player/browser module? No problem -- check out a couple of directories, fire up your favorite editor, write your code, check it in, and BANG, it's versioned and deployed. (Of course, you might want to have a test site or something. Since this is managed within svn, you can branch your code and set up two sites: one with the dev code, one with the production code, both running with content from the trunk. Or the dev site can have its own dev content. Or whatever. You get the idea.) When you back up the repo, you also back up every code customization you've made. That's one of the points behind boomstick: a whole site can be (more or less) easily managed as one project.

However, I also want it to be reasonably responsive and run on relatively cheap hardware (ie, mine) and that means that, at the moment, I'm allowing it to read content from the filesystem to reduce the number of calls it's making to the svn api and to make it easier for cocoon's caching system to manage things. Which makes it more difficult to sandbox sites. ALL OF WHICH IS TO SAY that while I can have multiple sites with whomever playing around with the content through the webui, I have to trust everyone who has access to the svn side of a site. And that's a problem, because it undermines one of the principle advantages of the system.

It's not a problem at the moment, since it's principally designed for people like me, who want to have multiple sites of their own. But it will need to be fixed, in time.

Added free links. I've been angsting about how to extend markdown, and I think I've found a vaguely non-evil compromise, which is of course shameless complicity. Oddmuse has their own defined markdown extension, which pretty much has everything I was thinking of, so I'll just implement the parts of that I like and call it a day. Which, again, means that now I've got free links. I implemented them in MarkdownJ, which makes me a feel a little oogy -- I'm inclined to do it as a preprocessor or something, but the markdownj codebase is already there, in all its glistening glisteniness. And there's the fact that after nearly a month I have yet to hear back from the current project maintainer about accepting my bugfix, for a bug that was some ten months old... so, I dunno. Maybe it's time for a fork.

God, I feel dirty.

Doing this is also helping me begin to settle on some decisions for document ids/namespaces, which is good. All of which dances around the bigger issue, which is getting the auth system to work properly in cocoon when sites (with virtual domains attached to them) are defined by subdirectories. But hey, progress is progress.

Okay, now I have a web form which writes to a file and posts it to the repo, which immediately makes it available to the webapp. Moving on with things, then:

- Editor needs to be improved so it's not lametastic.
- Auth system needs love.
- Module system needs to be reorganized, and needs to be renamed.
- Module system needs a basic inheritance model.
- Decisions need to be made about metadata.
- Virtual domain setup needs to be improved.
- Repo API needs an overhaul, and Repo should probably become a singleton.
- Need to make up my mind about how document ids are handled.
- Repo generation process needs to be rewritten so as not to be an embarrassment to my grandchildren.
- Markdown, while a precious little angel, really needs wikiwords.
- Search engine.
- Blah blah blah, "navigation."

None of these are particularly huge, but I don't want to devote a ton of time to this. Death of a thousand frickin' cuts. I think I'm gonna take a little while off and work on things that actually, you know, make money and advance the state of affairs for a while.

Why, why, why in the sweet lord's name, did I decide to reinvent the wheel for the eight millionth frickin' time?

Ah, yes: because I'm picky. And cheap.

This is too scary!!! We all know that the sites developed using Ajax tool kits and frameworks are not 100% accessible. Most Ajax applications use Ajax widgets that may or may not support accessibility. For example, a lot of Ajax toolkits don’t have support keyboard navigation (mouse-less operation). So every Ajax based website can be sued according to this ruling. Only exception is if the site provides non-Ajax version. But how many sites provides the non-Ajax versions which can be readable by screen readers? Gmail and Google maps has the non-Ajax versions(yes Google maps has the non-Ajax version which just displays the map as image with out any dragging/zooming features. Turn off Java Script and go to maps.google.com, you will see the non-Ajax version). But Google video, reader and all other Google products doesn’t have non-Ajax version. Similarly all live products from Microsoft except live mail doesn’t have non-Ajax versions. Yahoo has non-Ajax versions for most of their products as they have older versions of the products which they using as non-Ajax versions.

So do you think all these sites can be sued as per the ruling? Oh! boy this is scarier than I can imagine!

More hand-wringing and wailing and gnashing of teeth...

Raise your hand if you didn't see this coming. Oh, yes, Ajax is The Light And The Way. Hey, I know how we can recapture the glory days of 1997: let's find a way to make our websites more dependent on javascript!

Oh, if only there were some way to cleanly separate content from presentation, so that it was feasible to create a website that would render differently for different users with different needs.

Ah, if only.

I've got JavaSVN doing a bunch of basic things (import, update, checkout, commit), so I basically have everything I need to put together some kind webtastic ui for boomstick. It should also allow me to improve the repo creation process, which would be good, because the repo creation process is currently a nightmare. JavaSVN isn't slow once it gets going -- operations seem to average around a second each -- but instantiating it takes about 3 seconds, which I do not like. Also, I have yet to test it against directories with a large # of files. But, whatever. The last piece of the puzzle has fallen into place; I have a component that basically works that gives me I/O access into the repo. The pieces of the platform are all there -- cocoon, xslt 2.0, xquery, svn, java, markdown -- and more or less working together, so now it's time to actually, you know, write the application.

Well, not exactly. Now it's time to actually, you know, pull all the pieces together into a platform.

Well, actually, now it's time to add some new features and hope that sooner or later, you know, it all magically gels into a platform with an application implemented on top of it.









The evidence at hand is starting to suggest that maybe it's time to, you know, get some sleep. Goodnight.




Ah, the halcyon days of summer.

In other news, work on boomstick proceeds apace. I've cleaned up the codebase so that it's not an evil insane mess and organized it so that modules can be sensibly added (and so that much of its functionality is in modules.) Setting saxon as the default xslt processor was causing conflicts with xalan, so I changed it so that saxon (and hence, xslt 2.0 processing) is optional (on a transform-by-transform basis) and that seems to have cleared up those problems. All in all a lot of running to stay in place, but necessary and desireable. I initially just threw some stuff together to break inertia, and it needed to be whipped into something stable and sane to go any further. The one holdout is the process of building the repo, which is still thoroughly insane, but that's life on the streets.

It also now has a simple image gallery, and markdown support provided by markdownJ. In the process, I fixed a rendering bug in markdownj and built a markdown cocoon generator, so there's some of that old timey open source religion goin' on.