Sunday, February 4, 2007

Work on boomstick continues. Code that was unnecessarily integrated into the boomstick webapp (such as the markout generator) has more or less been disentangled into organs. Put together an organ grinder script to package organs separately from the core application -- still need to abstract that out for skins and valuemeals as well, but that's not huge. Also tested webdav support, which I get for free thanks to svn+apache -- short version is that is works about as well as your client. It's getting to the point where I could package a release. I'm inclined to, even though the repo api still needs to be, um, written. Perhaps a pre-pre-pre-pre-pre-pre-pre-alpha release, to get the code and some of my thoughts cleaned up.

I recently put together a simple RSS feed organ, and decided to write it in XSLT 2.0, which I also get for free thanks to Saxon. It probably goes without saying, but XSLT 2.0 is just a ton nicer than 1.0, simply by virtue of dropping RTFs and allow user-defined functions. I'd also like to add XQuery support, I'd really really like to, but there are apparently two hurdles:

- There is a conflict between Cocoon's APL and Saxon's MPL, at least for the Apache folks.
- Someone is going to have to get off their ass and write a generator.

Answers my question about why Saxon's never been included in Cocoon, though. Now, writing a generator probably (hopefully?) isn't that daunting of a proposition. There's nothing inherently hideous about writing Cocoon generators, and without looking at Saxon's XQuery API, I'd hope (pray) that I can just instantiate it, throw an .xql at it, and get back a DOM or a SAX stream or something. Which leaves the license issue...

Back in 2001, the dude who created Cocoon didn't think there was a legal problem with packaging APL and MPL code together although "it's not encouraged." So perhaps the licensing isn't an issue, either. I haven't figured out what license I'd put boomstick under, so that complication doesn't factor in, yet.

I dunno. Anyone have any experience with releasing code that incorporates third-party code with (possibly) conflicting licenses, specifically the APL and MPL?

Wednesday, January 31, 2007

I had a dream last night where XQuery was this very powerful science that was seen in fearful, almost magical terms by the laity. I guess this is perhaps an indication that I have been reading too many Dune references while watching too much Fullmetal Alchemist while doing too much XML programming.



"The declarative artifact engineers are extinct. Their fire has gone out of the universe. You, my friend, are all that remains of their religion."

Thursday, January 11, 2007

Released markout v13.1.0, as per here.

Thursday, January 4, 2007

MarkdownJ just put out a new release, which includes a small patch that I submitted a few months back. It's just a line of code, but it's nice to see. And it means I can remove the forked copy I was maintaining for Markout, which is nice.

I've got other, more scrutable stuff going on at the moment, but I guess the next thing to do in the coming weeks is to clean up boomstick enough that I could throw out an uber-basic 0.1 release or something. It still needs a lot of love, but it works, simple though it may be. I want to make what I've got presentable and get it out the door, so that improvements can happen openly, discretely, and as they are needed. I need get boomstick to a basic state of completion and rotate it to the background, into a supporting role, which is really where it belongs. The reason I started writing boomstick isn't because the world needs Yet Another Content Management System, or because creating one poses any particularly interesting problems -- it was because I couldn't find the tools I needed, that I liked, to support my other efforts. Boomstick is ultimately just a toolkit to allow me to easily put together web sites that are what I want, how I want, when I need them.

Saturday, December 23, 2006

Markout v13 released.

We (meaning "I") have now put up the inaugural v13.0.0 release of Markout, the Markdown-based wiki parser that will become something of a fixture in boomstick... And just in time for Christmas! Yes, this holiday season, give the gift that lasts a lifetime: free software. She'll love you for it.

Also, the astute may notice that my personal vanity page has been updated accordingly.

Tuesday, December 5, 2006

jll:

Why don't you just name the project and list yourself as the [project name] Team. I've seen several open source projects eventually piss off the owner so much that they refuse to work on it anymore. (Or they start raking in so much dough that they don't think it is worth their valuable time anymore.) Then somebody starts up a [project name] Team to take over and the licensing and support get all screwed up. Just assume that it will be wildly popular but piss you off to no end so you will eventually abandon it, and figure out the name of the group who should take over. Name it that.


nw:

This is a remarkably lucid analysis. Here I'd been thinking of picking a name I wanted to keep, but really I should be picking a name that I feel most comfortable drunkenly cursing.

Incisive.


jll:

I find it hard to believe that you would find any name uncomfortable to drunkenly curse. You could name it after an ex.


gibo:

Au contraire, some names are definitely better than others for drunkenly cursing. For instance, drunkenly curse anyone named "Tiffany" or "Britney" and you look like a fool for caring in the first place. Drunkenly curse somebody named "Vauldevarre" and bam, you're the person who gets killed in the next fifteen minutes of a Vampire Hunter D anime. ("DAMN YOU VAULDEVARRE!!!" *slice*) Names are actually absolutely crucial for contextualizing drunken cursing. My rule of thumb is to never drunkenly curse any name that sounds like it belongs to a porn star, or which Japanese people might consider Goth.
So, I'm about to put out an open source project. It's nothing big, just a couple of classes, an extension for a markdown parser that adds a kind of freelink and thereby turns it into a simple wiki parser. Nothing fancy. Now, the reason I'm doing this is because I want to integrate it into *another* project I'm working on, which is a wonky cms thing because there aren't already eight million frickin' cms's in the world already, and that last use of the word "already" was shamefully redundant.

So, I haven't released an open source project on my own before, so I'm debating what name to use to release it. Should I use my name, or should I make up some name like "Exegetic Labs" or "Throbbing Elephant Cock" or whatever? It would be nice to release these, and any future oss projects, under one consistent name. It would probably also be nice if, in the unlikely event that anyone else ever decides to contribute, that name is not strictly mine. There is, of course, no legally-recognized corporation/organization/etc. involved. I guess it'll probably only be relevant in license text and whatnot, and to a great extent this all probably doesn't make a bit of difference, but I love to other-think simple matters.

Opinions?