afongen

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.

A couple fun things coming up soon:

First, my colleague Sara and I will be providing accessibility training to MnSCU webmasters across the state. This is part of a strong effort being undertaken to highlight the need for accessible web resources, especially important since MnSCU (my employer) is both a higher ed institution and a government agency. It’s also an opportunity for me to completely rewrite our accessibility guidelines, which are based on the just plain sad and often incorrect Minnesota State guidelines. Part of me would just like to point to the W3C Web Accessibility Initiative, but that won’t cut it.

Second, my colleague Matt and I will be presenting a session on XML at the upcoming MnSCU IT conference. Matt is the guy who proved to me that client-side XSLT is workable; until then I’d been myopically convinced that server-side XSLT was the only way to go. Our goal is to demonstrate that XML isn’t just an up-and-coming technology, but that it’s here and can be worked into web sites right now. Matt will show some of the cool ways that he’s been using XML in his site’s back end (as a data store, mostly) and maybe some of his client-side magic. For my part, I’ll show a bit of XML and SOAP at work. Oughta be a party.