THIS IS ONLY HALF WRITTEN. I have been sitting on this post, waiting for the mood to finish it, for months; because EEP18 is now being treated as a likely implement, I am immediately publishing the half-written version, because it exposes many (though not all) of the serious, irreconcilable problems with EEP18.

On the mailing list, people are actively trying to bring Erlang up to snuff with regards to web standards. One of the more unfortunate choices being discussed is JSON as a data notation. JSON, unfortunately, does not actually map to Erlang in a useful way. Joe Armstrong has gone as far as to suggest BIFs, which are decidedly unrealistic as well as unnecessary. My goal is to create a JSON handling library. However, the mailing list is beginning to put momentum behind an alternative proposal which is currently presented in BIF form.

This post explains why my approach is different. Many of the issues herein are discussed by the tabled EEP (EEP 18, “JSON BIFs” by Rickard O’Keefe), but some are not, and some of these issues are accepted when I believe they should not be. It is my position that EEP 18 is unacceptably dangerous. I will explain why.

My boss’ boss, Varun, is letting me open source some of the work I’m doing at Kayako. I’m not supposed to talk about the interesting three until they’re ready for release, but I can tell you that a JavaScript ISO8601 implementation is among them, and that they’re all going to be MIT licensed, no GPL contamination.

More news as I get my butt in gear and finish the libraries in question. But, yay Varun!

I’m going to be releasing a few new libraries in the next several days, both by archive and public subversion. I’ve already bought the domains and built a forum for them. I even wasted a couple hours subversion automating everything down to the line of having little library websites made automatically, with custom per-library color palettes.

I was a little bored.

So we’re going to have three libraries progressing in the immediate future, with quite a few more over time:

In the near future, I will add C++ and PHP libraries, as well as many some libraries for more obscure languages like FormulaONE, Mozart-Oz, Factor and maybe (sadly) Delphi. I have more than 30 libraries ready for release.

All those repos are pretty empty at the moment. That will change in coming days, and I’m sure I’ll post lots of boring little snippets here about whatever minor new thing my crap does.

The most common cause of a blank screen at any stage in the process, if your source view shows empty, is that PHP aborted during its run without dumping buffers. During software upgrades, this is usually due to one of three reasons:

An incomplete transfer of the requisite files. Don’t insist that you’re certain that didn’t happen, even if it’s from a command like svn or cp that shouldn’t fail; you’re not certain until you’ve checked.

PHP has run out of some resource, typically RAM.

mod_security is set up brokenly

[digg-reddit-me]In both cases, you can figure out which by checking your apache logs. On windows, go to the Windows Event Viewer. On unix, this may live in a variety of places; most common is shared hosting by cpanel/plesk, where you can get it in your control panel, or to just look in /var/logs/ .

If it’s #1, you’re likely to see something like this in logs (this is from my site, which just suffered this problem and was quickly fixed) :

I’ve been thinking about making an image plugin for WordPress. I want to restart my image of the day process, but the import process has been dreadful, and there’s no programmatic access to the image list, meaning things like random images and images from subgroups aren’t particularly reasonable. To that end I need to write my own, and since I’d love the rank that comes from having a high-usage plugin, I need a clear idea of what things go into an image plugin, what features are missing from existing plugins, et cetera.

I’m already doing complex efficient randomization, API access, bulk posting, timed bulk posting, base autotagging, auto-categorization, a catalog widget, and I’m going to make sure that my stuff is compatible with the All In One SEO pack. I’m going to provide integration points, and I’m going to provide an example integration with LightBox, or one of its relatives. I’m going to provide voting, moderated tag suggestion and home-post permalinking.

Yeah, so, I’m having a hard time adressing the weirdness that is ParentNode’s approach to default functions. Basically he sets a hook on the prototype for calling the function, and in that he makes a new function which checks for the presence of a particular member (we remember that functions are objects in ECMA, I trust.) If that member exists, he chops it up, and for each argument in the original function call, he tests for undefinedness, and if that’s present, he fills in the value. (This one is order-based default, but there’s also a by-name default.)

Now, I think it’s a little impractical, and it leads to a mind-bleedingly weird syntax, but it’s actually struck me that this is a very clean, very terse format for providing something akin to uniform construction behavior when you’re dealing with multiple manufacture paths to a given object. Granted, it’d be an even bigger, even uglier hack, but still, it’d work.

Witness syntax:

function exampleF(foo, bar, baz) { … }.defaults(1, 3, 7);

Hear that crashing sound? It’s your mind, breaking. But, as much as I hate to admit it, this is one genuinely lovable hack. Bravo.

MSHTML is an awesome user interface tool, but it has a whole lot of standard behaviors, many of which aren’t what one wants for an application (since it’s designed for the web.) This is a list of stuff you need to do to embed IE COM and have it behave like a normal application. There’s more than a person might expect.

To be plain, I think the XMLHttpRequest object is quite wonderful. It’s a deeper realization than I’d had when I was talking about RFC2557+ some years ago; rather than binding people to URLs, it frees them to use sockets.