Solipsism Gradient

While reading the links pertaining to the previous post about a “back” button for the iPad – and, incidentally, for the Mac – it occurred to me that such a capability might be built into a future version of my Klicko utility. Which is Mac-only, of course. For now, Apple doesn’t allow any sort of utilities for the iPhone/iPad, more’s the pity.

I’m rather overloaded at the moment, moving out of my apartment only a few days before going off to WWDC, and I’ve got an iPad app prototype to work on, too; but I’ll definitely look into this as soon as possible. I think that most of the infrastructure, in fact, is already in place inside Klicko.

I did download the Universal Back Button App, but didn’t have time to check out how it works; at any rate, it seems to be quite different in implementation.

Brent Simmons, author of NetNewsWire, writes:

On Macs we have a long-standing culture of apps working together.

…

On the iPad (and iPhone) we can sort-of do the same thing. We don’t have AppleScript or Apple events, but we do have the URL scheme thing for inter-application communication. It’s technically possible to do some of these same things.

But we don’t have an easy way to get back to the calling app.

…

What if the calling app added, as a parameter to the URL, a URL to call when the task is completed?

This way the helper app (NetNewsWire in this case) would know, once the task is complete, how to get the user back to their place in the calling app (Twitterrific in this case).

I was thinking about the same issue, coincidentally, and one idea which occurred to me is to use the equivalent of the http referrer URL (often misspelled as “referer” for historical reasons).

For  a standard http request the referrer is the URL of the document containing the clicked link, so you can get back to that document by clicking on your browser’s “back” button. Now, this isn’t really contained in the URL itself – rather, the browser appends this as one of the fields in the http request headers – but the analogy is interesting.

For this to work locally between applications, the referrer URL would need to be set into the URL targeted at the called application. And indeed, there is a -[NSURL setResourceValue:forKey:error:] method that, in theory could add any key/value pair to the URL. (Currently only the “scheme” property seems to be available, though.)

Update: Mike Abdullah points out in the comments that, in practice, this method applies properties to the file a file URL points at, not to the URL itself. Drat.

On the receiving side, the “referrer” value would have to be pulled out from the NSAppleEventDescriptor that the application gets with the ‘GURL’ event.

All this needs filing enhancement requests and Apple would have to do the required twiddling inside their code base – or rather, bases, as this would be useful to have both on the iPhone/iPad and the Mac side. It would take a long time, if it’s done at all.

The alternative would be to developers to, informally, establish a convention for incorporating this into the URL itself. So we’d have something like:
calledscheme:///the/url/parameters&?REF=callingscheme://some/url/to/return

Probably the second part would have to be suitable encoded/escaped, too. Maybe this would be a good topic for discussion at WWDC?

Interesting piece by Sean Heber aka BigZaphod.  Remember my post about the significance of Clang/LLVM on the iPad?

I think there’s a chance that Apple is slowly building Objective-C into a managed environment similar to Java/.NET. At some point in the future they could define an Objective-C HD (or whatever :P) that no longer maintains total compatibility with C. Since they use LLVM a lot now, they can even use that to analyze your code to make sure that pointer accesses are safe and controlled. Anything that isn’t safely confined to your own app would be an error. Access to the Objective-C runtime functions could possibly even be revoked. After which point, Objective-C HD no longer compiles to machine code but instead to an intermediate representation.

By doing something like this, they can abstract the actual underlying CPU hardware and architecture out of the applications themselves as well as maintain a truly safe sandbox where private and undocumented APIs simply will not be allowed to work. Apps on the App Store would be submitted in this intermediate format which they can translate into the machine code that’s native to whatever CPU happens to be in the device you’re downloading the app for or they could simply put a JIT in iPhoneOS (although there’s no reason to waste the CPU cycles on the device if they can translate them once on the backend – at least for mobile stuff).

Pretty much complementary to my reasoning.

After checking my server logs I found several messed-up redirects. Old bookmarks and RSS feeds should all be working now…

Here’s a brief rundown on what’s new here – it’s not just the pretty colors.

First, the “dumbass folly” “noble experiment” of using phpbb forum software for my blog has been officially terminated – as you can see, I’m now running WordPress like everybody else. The upside is that now commenting is much easier, and you don’t need to register to comment.

I’ve spent some time going through all the old posts, adding tags and categories. Hopefully I’ve been able to do so somewhat consistently, to make searching easier. All my personal topics have been merged into this blog stream.

The support forums have been upgraded to phpbb version 3 (for a few days, I considered using bbpress but it wasn’t enough for my needs). There, too, users will be able to comment without registering. There’s a huge list of registered users brought over from the old forums; I’ve rejected quite a few obvious spammers, and users registered over the last 14 days may have been lost. Also, I think that some user’s passwords may not have survived the migration process. However, as I said, it’s no longer so important to be registered at all.

In exchange for allowing free posting to anonymous users, all comments and posts on both blog and forums will be held in a moderation queue; the spammers have already been at it, but “none shall pass”.

Links to older posts should be automatically forwarded to the appropriate WordPress permalink or to the new support forums, depending on the topic. The RSS feed URLs have also changed; some readers should switch you over automatically, but be sure to check.

As you may have noticed, I’ve integrated the product pages and other static material to use the blog’s theme. I haven’t quite figured out a fully theme-independent way of doing so, since I could find no theme that both supports that and looks “just so”; expect the current theme to stay in place for quite some time (maybe not 7 years like the last one, though 🙂 ).

If you see this, it means that the new site design is up.

Hope you like it; details soon. Not everything could be transferred successfully, please recheck and update any links or RSS feeds you might have pointing at old URLs.

Well. The rising tide of modernization has finally caught up with me, and the infrastructure of this blog, and of the support forums, will be dragged, kicking and screaming, into the 3rd millenium. And all this will happen in the next few weeks.
In other words, all the brass gears, vacuum tubes, hamster cages and whatnot that have powered this site for almost 8 years will be torn out and replaced with gleaming quantum exterocitors powered by the adeledicnander force. Or something.
The support forums will, at the very least, migrate to phpbb 3, and I may seize the opportunity to convert this blog part to WordPress. I’ll be studying the implications.
Meanwhile, I’ve pretty much decided to make a stab at doing stuff for the iPad – I’ve found a guinea pig client for one – and in line with that, will attend the upcoming WWDC. More about that in a few days, after my confirmations for tickets and so forth.

richardl wrote:

Rainer, it is interesting to note that Adobe built their ActionScript/Flash compiler for iPhone on top of LLVM.

http://cs.illinois.edu/news/2009/Oct8-2

http://www.adobe.com/devnet/logged_in/abansod_iphone.html

Thanks, I wasn’t aware of that. However, I don’t think that this invalidates my original argument, which is more based on Clang than on LLVM. Christopher Lloyd also remarked on this:

…Yet Adobe uses llvm for the compiled Flash, so they don’t like Adobe’s parser? silly. http://bit.ly/MQtRZ

Also thanks to Daveed Vandevoorde, who remarked that the LLVM bytecode isn’t as platform-independent as I thought – things like sizes of variables and ABIs (Application Binary Interfaces) stand in the way. Still, it’s not impossible to see Apple defining a generic target platform, in terms of sizes of pointers, integers and so forth, and a specific endianness and runtime ABI, and then staying within the bytecode for that.