Just a little over a week ago, Chris Lattner announced to the Clang mailing list that Apple was adding something called "blocks" to C. These blocks are basically closures in the same sense that any computer science student would use them in Lisp, except with a few extra twists of memory management thrown in. (Specifically, if you want to mutate variables declared outside the block, you have to use a new storage qualifier, __block.)

Today, the anticipated "Objective-J" framework used to build the impressive 280 Slides web application was released, along with a Cocoa-inspired (almost Cocoa-cloned) framework known as Cappuccino. In some cases it seems almost too close, with methods like -[CPWindowController initWithWindowCibName:], where "cib", of course, stands for Cappuccino Interface Builder. (I'm not sure this exists yet; I can't find any mention of it on the site.) But given that GNUStep is still around and OpenStep, I think, is still open, I suppose there's not technically any copyright infringement going on. I'd like to play with Cappuccino too but I have enough on my plate right now.

Anyway, so I think blocks are cool, and would like to start using them except I try to maintain backwards compatibility. (Think about alert sheet callbacks, though!) Objective-J is pretty cool but I want to see some performance specs (though I'm sure it's faster than an overly-AJAXed site).

What I find interesting, though, is this snippet from the Objective-J Tutorial's Methods section:

You may be wondering why it matters what the actual name of the method is. One pattern you'll find in Objective-J and Cappuccino going forward is the idea of passing a method as an argument to another method. This is used commonly in delegation and in the event system. Since method's aren't first class objects in the same way as JavaScript, we use a special notation to refer to them, @selector. If I wanted to pass the previous method as an argument to another method, I would use the following code:

[fooObject setCallbackSelector: @selector(setJobTitle:company:)];

As you can see, the method name is passed to @selector complete with its colons and parameter labels.

At the same time, Objective-C, and indeed pure C as well, gets the use of blocks:

// something like this
[fooObject setCallback:^(NSString *title, NSString *company) {
    // do stuff
}];

...and while this is no good for bindings, and maybe even not target-action replacement, it's great for callbacks.

Ironic that the two languages seem to pass each other in the mist. Personally, I've been finally won over to Blocks since they don't seem to mess up C at all (unlike some other closure syntaxes I've seen which only work in a high-level environment). Whereas although using JavaScript functions as first class entities isn't always needed, it seems like it wouldn't be hard to implement. Maybe it was just a problem of copying the syntax a little too closely. *grin*

If you've been running your own server for a while, eventually you'll start getting privacy jitters and want to use HTTPS, at which point you'll either happily set it up with minimal difficulty (if you're running a single site) or realize frustratedly that you can't use HTTPS with name-based virtual hosts. To quote the Apache site:

The reason is very technical, and a somewhat "chicken and egg" problem. The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this, mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to go to the correct virtual server Apache has to know the Host HTTP header field. To do this, the HTTP request header has to be read. This cannot be done before the SSL handshake is finished, but the information is needed in order to complete the SSL handshake phase. Bingo!

If you're not looking for a solution to this problem, you should probably stop reading here. Otherwise, read on—but be warned that I don't have my configuration files handy, so I may get some of the details wrong. Correct me in the comments, please. You must have mod_rewrite to use these instructions.

So, Apache won't do it for us. If you want to implement this solution, you have to give up the use of the <VirtualHost> directive, and any per-host configuration settings that aren't allowed in <Directory> or <Location> sections. Before you do that, note that Apache will allow you to set one virtual host as using SSL, just by adding it to that host's config and having the host listen on port 443. This is only for two or more hosts; I think in that case Apache will default to the first one it reads.

Step 0: disable virtual hosting on port 80. Use NameVirtualHost *:443 to allow separate settings for SSL connections.

Step 1: Add the following sort of code to your main config file. Again, I don't have mine handy, so I'm giving you the general idea.

# This is the site that will be displayed if mod_rewrite isn't enabled
DocumentRoot /var/www/html/main-site

<IfModule rewrite_module>
	RewriteEngine On

	# Change this to the path to your sitemap file (see below)
	RewriteMap sitemap txt:/etc/apache2/sitemap

	# It's this line that may not be correct
	# And getting it wrong can result in infinite loops
	RewriteRule ^ ${sitemap:%{HTTP_HOST}|%{DOCUMENT_ROOT}}%{REQUEST_URI}
</IfModule>

<VirtualHost *:443>
	SSL on
	# fill in the rest of your SSL settings here

	<IfModule rewrite_module>
		RewriteEngine On

		# Change this to the path to your sitemap file (see below)
		RewriteMap sitemap txt:/etc/apache2/sitemap

		# It's this line that may not be correct
		# And getting it wrong can result in infinite loops
		RewriteRule ^ ${sitemap:%{HTTP_HOST}|%{DOCUMENT_ROOT}}%{REQUEST_URI}
	</IfModule>
</VirtualHost>

Step 2: Create your sitemap file. This is a rewriting map that maps site names to filesystem paths. Mine looks a bit like this, though don't rely on it for hacking me...

# These entries are technically not necessary since it's my DocumentRoot
belkadan.com		/var/www/html/belkadan
www.belkadan.com	/var/www/html/belkadan
# Look! Another "host"!
mail.belkadan.com	/var/www/html/webmail
# etc

Step 3: Convert your old virtual host specifications over to use <Directory>. I think you can handle this on your own, but remember to run a apache2ctl -t to see if you're using any host-specific directives that just don't apply to <Directory> sections. The one that popped up for me was CustomLog; all my logs are back to one monolithic file.

Step 4: Reload Apache and hope things don't break. Test all your sites with both HTTP and HTTPS.

And that's it! Well...nearly. You can stop here if you want, but if you want special handling of certain locations, you have to implement a namespace system for yourself. I decided that paths starting with /._ were virtual paths. This actually affects your rewriting rule.

Step 5: Change both your rewriting sections to look like this. The [PT] parameter means "pass-through" and it sends the rewriting results to other URL-to-filesystem modules like mod_alias.

<IfModule rewrite_module>
	RewriteEngine On

	# Change this to the path to your sitemap file (see below)
	RewriteMap sitemap txt:/etc/apache2/sitemap

	# Careful with these lines
	RewriteCond %{REQUEST_URI} !^\/\._	
	RewriteCond ${sitemap:%{HTTP_HOST}|%{DOCUMENT_ROOT}} ^\/\._
	RewriteRule ^ ${sitemap:%{HTTP_HOST}|%{DOCUMENT_ROOT}}%{REQUEST_URI} [PT]

	RewriteCond %{REQUEST_URI} !^\/\._	
	RewriteCond ${sitemap:%{HTTP_HOST}|%{DOCUMENT_ROOT}} !^\/\._
	RewriteRule ^ ${sitemap:%{HTTP_HOST}|%{DOCUMENT_ROOT}}%{REQUEST_URI}
</IfModule>

Step 6: If you're using fancy indexing, change all references from /icons to /._icons. Apache uses the Alias directive to resolve the location of the indexing icons, so you need your rewriting system to take that into account.

Step 7: Add your special-case sites to the sitemap file. Let's pretend we're adding WebDAV capabilities, and for some reason you want it on another host.

# all the stuff from before...
webdav.belkadan.com 	/._webdav

Step 8: Change your special-case virtual hosts to use <Location>. This is useful for something like "Dav on" or "Require valid-user", which you don't want to do for normal access to your main site! Unfortunately, <Location> allows even fewer directives than <Directory>, but you can get around this by setting an environment variable and using an <IfDefine> later.

Step 9: Add an Alias directive for your special-case virtual host.

Alias /._webdav /var/www/html/belkadan

Step 10: Secure your special-case virtual hosts. Right now anyone could access the hypothetical DAV by going to http://belkadan.com/._webdav. Block that by adding code like the following:

<Location /._webdav>
	# All of your config settings here, then...
	Satisfy all
	SetEnvIf Host ^webdav\.belkadan\.com allow_alias_access
	Allow from env=allow_alias_access
</Location>

Step 11: apache2ctl -t, reload, and test. And at this point you should have a working configuration, with HTTPS available for all of your sites.

I'll dub this technique "virtual virtual hosting" and leave you with the fallout of the pun. Oh, and I think there's probably a better way to handle the special cases rather than using a made-up path (a separate host-based SetEnvIf would probably do it), but this is what worked for me.

Quickie for today that some people might find handy. (I need to start posting much more. And reorganize a bit.)

Just yesterday I found myself wondering what to do when Dockyard would crash. The new Dockyard uses the wonderfully transparent distributed objects of Cocoa, which become staggeringly destructive when the remote process crashes. If you only used the data in a few places, or transferred everything by-copy, then you can probably recover. But in the bindings-intensive AppKit world of Dockyard Manager, you're going to crash before you can say [[self window] close:nil] (I tried.) The bindings all try to update and come back complaining about a broken connection. The only thing that worked was to bail out, but if I tried to show an NSAlert to tell the user we had to bail out, the app got stuck in the modal loop. I have no idea why, but I can only assume it's because the hordes of orphaned object proxies have destroyed all of the run loops by this point.

(I'd like to know why I can't just use NSAlert, but I have no idea where to go from the bit of poking I did. Pausing during the alert reveals an apparently normal run loop, but the alert simply won't close.)

So, I have decided instead to bail out as planned, but to show an alert after the application quits. (Huh‽) Rather than use AppleScript's "display alert", which doesn't look as nice, requires twice as much space as my final solution, and (the clincher) doesn't work on Panther outside of AppleScript Studio, I wrote a small application intended to be called with a property list file describing the parameters of the alert.

The application wouldn't be so remarkable, except that it works and it's nibless. Even if you don't care about the app itself (to be fair it's really odd to want to display an alert without having an application context already, and a better sudden death app might be needed in the end), you might still be a bit interested in how to write a nibless application.

Summary: nibless faceless application that displays alerts based on a property list file description. If you're interested at all, you can download the source to what I've named Alert Notifier.