Pete Lacey’s Weblog

Why do I always end up responding to Tim’s posts?

Today Tim discusses the sad state of affairs with blog authoring tools. I too have tried Ecto and MarsEdit. In my opinion MarsEdit is superior (and more Aqua-y), but, as Tim says, it has a ways to go. When my 30 day free trial expired I removed it and went back to the WordPress HTML interface.

Anyway, here’s a thought on how to solve this. I don’t think anyone should be creating a blog authoring tool and then grafting on the HTML WYSIWYG goodness. Instead, it should be the other way round. Find a nice HTML editor and add support for the MetaWeblog API and UI support for bloggy notions of categories and trackbacks, etc. And if you’re looking for a nice, cross-platform, HTML editor, well, here’s one right here: NVU. NVU is derived from the Mozilla composer source base and already works on Linux, Windows, and Mac. And best of all, it’s open source, so someone smarter and younger than I am should be able to graft on the code needed to make this work as a blogging tool. I’d pay for that.

My wife has invited me to post a reply to her unprovoked attack. Herewith:

(postiions thumb on nose, wiggles fingers) “Nyahh, nyahh, nyahh!”

I am not subtle.

Tim Bray notes that the debate over open source licensing is getting increasingly shrill, indeed taking on an almost religious fervor (he refers to the “church of Free software”). He links to Simon Phipps who neatly decomposes the current assortment of open source licenses into three main varieties: the GPL, BSD-style, and MPL-style. On reading these two posts it occurred to me that I’ve seen such a schism before. So, for those of you who still can’t keep it straight;

It’s been a while since I’ve posted. I’ve been distracted by work and by a simple social-networking experiment.

I’ve owned the laceys.org domain since 1998, but I haven’t done much with it. This weekend I pointed the domain at my web host, Rimu Hosting, updated the VirtualHosts table in Apache, and installed a Wiki. In particular I installed PmWiki with the FixFlow skin.

The intent is that members of my immediate family will flesh out the site with information about our parents, our neighborhood, and themselves. I’m hoping that it doesn’t become a dry recitation of facts, but a place for stories and anecdotes. But that’s really besides the point, as I expect that only a dozen people in the world will be interested in reading it, and six of them are me and my five siblings. The real goal is simply to get the family to participate on a project. I suspect it will be a spectabular failure as I am the only one of us with any technical bent at all. Honestly, on a scale of zero to ten, where, say, Ken Thompson is a ten, and my mother, who literally refuses to be within a few feet of a computer, is a zero, my brother and sisters probably average out to about one. However, wikis aren’t that hard, and PmWiki is nice, so we’ll see.

But mostly, I guess I just did this for grins.

Oh, and I locked down the site so that only my family members can edit it. I did this with the UserAuth plugin to PmWiki.

Two of the goals I have for the Moxie messaging system is to use the Tuple Space architecture and to have completely autonomous messages; that is, messages not tied to a particular transport and not necessitating a request/response architecture. I’m not sure now, however, that this can be done to the ideal that I had in my head.

For one thing, I’m not going to have an Internet distributed Tuple Space. I never planned to, mind you, but it seems that if I don’t, then I really don’t have Tuple Spaces. The problem here is that a Tuple Space, regardless of how many machines make up that space, is supposed to act like a virtualized memory store. Spanning such a system across the Internet is probably not doable.

That’s okay, what I wanted was a local Tuple Space (TS) that can post messages to and receive messages from other TSs. More accurately, my original conception was to have senders post their message to any TS, along with the address of the TS it is expecting replies to be sent to. This is easy enough to visualize.

However, I also want to support message intermediaries. That is, any number of other processes could sit in the message flow without anyone necessarily knowing. This is the primary driver for autonomy and pulling what is normally at the transport level up into the message.

In thinking about this, though, it seemed it would be more straightforward, and would make securing Moxie servers easier, if “particpants” read from and wrote to the same Moxie server. If any messages were intended for a foreign server, then the first could route it on. This is analogous (exactly the same, really) to how email MTA’s work today.

This allows me the latitude, should I need it, to have one protocol for local Tuple Spaces — at least for reading from them (ala IMAP or POP), and another for interconnecting Moxie servers (ala SMTP). This, of course, raises the question of why invent email all over again. Well, I’m not, I’m inventing Message Oriented Middleware all over again, but this time with XML and without the baggage of SOAP and WSDL and UDDI.

Up next: The Moxie Message Format.

In my previous post I forgot to come up with a port number for a Moxie server. I have big dreams, so I’m picking a low number. According to IANA 26 is free, and it’s right next to SMTP (the other asynchronous messaging system). Who knows, maybe Moxie will grow up some day to actually officially own port 26. For now, it’s my system and I’ll listen on any port I want. In the future I might need to change this to some port above 1024, if client applications need callbacks. Time will tell.