I've been toying with architectures for the Ultimate Content Management Application, a bit of vaporware that's suffering from Second System Effect before I even come up with a coherent plan, and to do this I've been looking at content management systems. Well, ok, I've been trying to look at content management systems, because almost everything I find that a) calls itself a content management system and b) is free, is not a CMS, it's a bad slashdot clone that lets you take the dates off the entries. I'm sure there's more to content management than there is to a blog, but I can't find any evidence to the contrary. Of course, there might be expensive things out there that do what I'm imagining, but nothing I can download. Which is no bloody good, I want to play with a Real App.
This is in weird contrast to this megnut which complains that most blogging engines are bad content management systems that let you display date-based lists of entries and call themselves blogs. Weird. So, are there any CMSes out there I can play with? Preferably written in perl...
thanks to blech for the megnut link.
Muttley caused this train of thought. Blame him.
Thoughts for a blogging toy
Here's something I might do. Every time I post a blog entry, people on a list could get a mail with the subject, contents, etc, just like I actually just sent the thing to a mailing list. People can reply to the mail, and their replies get put as comments on the blog entry, as well as mailed to the rest of the list. People posting comments from the web page, their comments go out to the list. So if you ignore the mail aspect, it's a traditional blog, and if you ignore the blog aspect, it's a traditional mailing list, albeit with the caveat that only the owner of the blog can start a thread. And hell, that's optional, you could allow free posting...
Once you do that, of course, the blog could be viewed as merely a web based archive for the mailing list, just with a much nicer web interface than most mailing list archives. Blogging software has put a lot of effort into managing date-based information archives, much more than mailing lists. On the other hand, mailing lists have put much more effort into managing threaded conversations than blogs have.
This blurs the line about what it is, of course. I'd probably initially implement it as a blog, with a bit of mail glue attached, but I suspect the more elegant way would be to have a mailing list with a very sophisticated web archive attached to it, one that handles threads as entries, and that allows you to post to the mailing list through the archive page. The distinction between the two rapidly becomes moot, of course.
Hmmm. Must play with siesta
(later) More Rambling
So, muttley has rambled as well. Interesting. He has some ideas about multiple blogs tying together somehow that I'm not seeing a way of making work in my head, and I hate talking about things I can't construct a nice working mental model of, but he's right, it would be nice to have a system of mutliple blogs tied together. Like this.
You get thread ownership problems, though. As things stand, I control a conversation on my blog completely. (well, if I had comments working yet...). That's ok if the blog is also a mailing list, because I'd control the mailing list server completely as well. But if, say, threads I started were hosts on my blog, and threads paul started were hosted on paul's blog, we get issues of potential censorship, and people picking the thread to comment on based on who's blog the start thread was on.
That issue asside, it's quite easy to adapt the first model espoused above to this sort of thing. All the participating blogs would send stuff to the same mailing list, and the mail reciever would use some smarts to determine which mails were replies to which blogs, and post comments appropriately. All doable. For the second, more elegant, solution, where the blog is merely one way of representing the 'message' objects that the back-end understands, we'd either need to host all the blogs in one place, or have a distributed server, or something. Not sure.
Tell you what. I'll actually implement something at some point, and we'll see how easy the collaborative stuff is then.
After much muttering back and forth between blech and I, I have written and released AudioFile::Identify::MusicBrainz. The old MusicBrainz client relied on the C library they distribute, which was silly for something that sent and recieved pure RDF, so a pure-perl implementation was just begging to be written.
So, upsides, it works, there's exactly one sort of query you can send it, but that's fine, it's the important one - you can say 'I know this about a track, tell me more'. The next step is to give the user a nice choice, and then let them write the updated information back into the ID3 tag.
Downsides, I'm not using 'real' RDF parsers, I'm using XML::DOM. This worries me, frankly, I'd much rather do the right thing, but I get a headache trying to make the perl RDF stuff work. There's an RDF::Simple out there now, though, so maybe I'll try that...
I'm going to get a reputation here for stupidly long module names, you know.