afongen

While thinking about a redesign for this site, I’ve also been wrestling with the content management/updating side of things.

On the one hand, as Paul Sowden has pointed out about his own site, the site content is updated much less frequently than it’s accessed, so static files make a whole lot of sense. I’d like a system in which each entry can stand alone as an XHTML file, be served up and make sense. Archive groupings can be built from these individual files.

On the other hand, I’m generally not comfortable with systems like GreyMatter and Movable Type, which edit static files but generally require those files to be world-writable. There are ways around that, of course, but I am still drawn by the notion of using an RDMBS instead.

If I store entries in a database, though, I want to be able to pull them out to static X(HT)ML files without a lot of hassle. As I’ve indicated before, I very much believe that for long-term flexibility, XML is the way to store content. It doesn’t matter much to me whether the XML docs are stored on the filesystem or in a database somewhere. I’ll likely end up writing my own rather basic system that stores individual entries as XHTML documents in an RDBMS. It’s probably not necessary to roll my own, but I feel like it. Good for the soul and all that. As usual, it’s just a matter of finding the time.

Then there’s the matter of different page elements like navigation menus, the news feed, lists of links, and so on. I use a template system right now so that I don’t need to update every page whenever I change or remove one of those sections. The most recent version of each page element is served up every time a page is requested. Each of those sections is actually an XML file that’s parsed and converted to XHTML on the fly. Honestly, I’d like to do this with JavaScript instead of PHP/Perl but am concerned about accessibility: do I really want to prevent non-JavaScript-enabled user agents from access to that information? On the other hand, is it really essential content or is it just something extra that’s available if you happen to have JavaScript? That’s a coward’s way out, though, using an argument more suited to effects like rollovers or hierarchical menus than actual content. The response is the same: I will use JavaScript to add those sections to the page but offer an alternative method to access the content, probably on a separate page.

First, though, I’ve got to push out a new design. Back with that soon.

A coworker casually mentioned this article on ZDNet citing a .NET Developer Platform architect from Microsoft who suggested that we look for a replacement for HTTP for web services. I thought it interesting, but nothing terribly new, since yeah HTTP is kinda pushed to the limits with some of the things coming down the pipe. It seemed to be more an article intended for upper management’s consumption rather than serious techies’. Before too long, though, I saw a number of irritated comments out there (scottandrew, oreillynet, PHP Everywhere…).

I don’t understand this. Am I missing something in the tone of the article? Or are people just reacting to the fact that it’s someone from Microsoft who’s suggesting another protocol? I thought that debates about the the suitability of HTTP for web services have been going on for a while now. I recall Simon St. Laurent mentioning this almost two years ago. It’s discussed in both O’Reilly’s XML-RPC book and their SOAP book, which mention other protocols like BXXP, apparently now called BEEP. We have Jabber-RPC, in which XML-RPC messages are being carried over Jabber (not that anyone ever seriously expected that to replace HTTP, it’s just damn cool).

So why the uproar? We should think about these things now so we can lay down a decent infrastructure, one that’s robust and secure.

Of course, I write this at the same time that I’m designing web services to run over HTTP, probably on port 80. Heh. Nothing that exposes large interfaces to massive, mission-critical systems, though.

Alex Russell has some worthwhile things to say on the matter, as usual.

Last night I dreamed that Pat Robertson had declared computers to be satanic because he’d read a mistranslated manual that referred to a “dumb-ass terminal” instead of a “dumb terminal.” I was laughing so hard in my sleep that I woke up Kiara, who woke me up to see what was so funny.

What I would likely be doing today if I were not hauling out boxes and boxes of our belongings, preparing to move: playing with DBD::SQLite. In planning a redesign, I’ve been thinking of different ways that I could store page elements. An RDBMS is one of them, and while I like MySQL, I am intrigued by SQLite.

But that must wait for another, chillier day. The weather’s gorgeous today, so I’m heading out.

In response to my post the other day about detecting wireless devices, a kind “Web Developer Evangelist” from a company called Dokoni writes with a few sample HTTP_USER_AGENT strings:

• UP.Browser/3.1.04-SY03 UP.Link/4.3.2.3
• Nokia6210/1.0 (03.60)
• Motorola VoxGateway/2.0
• Palmscape/PR5 (PalmPilot Pro; I)
• Mozilla/1.22 (compatible; pdQbrowser 1.08; PalmOS 2.0)
• Mozilla/1.0[en]; Go.Web/1.1 (compatible; MSIE 2.0; HandHTTP 1.1; Palm)
• Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; 240×320)

Oy. Somehow I was hoping that this would be easier or that there might be some reasonable standards emerging in UA strings, but it seems not. I can understand why a company would make a go at selling a product that sifts through this morass to do something useful with the information.

Anybody know anything about how to detect a PDA, cell phone, or other WAP/WML-enabled device? I’m looking to serve up WML or a different style sheet but am not sure how to check for these devices. I’ll do some Googlework but thought someone might know offhand. If so, please email me. Thanks.

Update: Hmmm, it looks like you can check HTTP_ACCEPT for text/vnd.wap.wml — the MIME type for WAP/WML. Great, but how about HTTP_USER_AGENT? The Ultimate Browser Sniffer doesn’t really go there.

Not a bad article on Zend on Secure Programming in PHP. Deals with some very commonly overlooked vulnerabilities. The best I’ve seen, though, is still A Study in Scarlet: Exploiting Common Vulnerabilities in PHP Applications.

For the color impaired, like me: Color Schemer.

I’ve just finished the mod_perl Developer’s Cookbook. Excellent. Truly excellent. This is the book that I wish I had when I started into mod_perl. The Eagle Book is essential but was a bit much for me the first time I read through it. Now that I’ve been working with mod_perl awhile, and especially now that some things have been clarified for me by reading the mod_perl Cookbook, I feel that I can tackle the Eagle Book again and get a whole lot more out of it. With all the handy and well-explained examples in the Cookbook, many of which show how to do things I’ve been wondering about for a long time, I feel ready to tackle some of the tougher projects that I’ve let languish. I have so many, many ideas for things that I want to tackle with mod_perl.

What’s so special about mod_perl, you ask? For starters, and I admit that this was what sparked my first interest in it, it embeds a perl interpreter in the Apache server, cutting down on the startup time that causes the bottleneck in a CGI environment. But hey, that’s what mod_php does, so maybe you think that’s nothing special. And although important, it’s hardly what I find most exciting about mod_perl. No, the beauty of mod_perl is that it offers hooks into the Apache API: access to the server’s internal processes. The power and flexibility that this affords the developer makes me giddy. And terrified.

Every now and then I find myself in a discussion about the merits of one web server over another (usually IIS vs. Apache). mod_perl is one of the top reasons that I like to use Apache.

In case you’ve been wondering when to use <abbr> and when to use <acronym>, that message should make it clear. As it turns out, I’ve been misusing <acronym>. Stupid me. It should have been clear, but I was overgeneralizing and using <acronym> for things like SVG. Oh well. Live and learn.