Migrating from C to C++ back then, we all had to get used to the this pointer. The this pointer, of course, identifies the object that is supposed to perform the service that we requested. It must have been a good idea, because these days, it’s pretty much in all programming languages (even in Perl!).

It’s time to introduce the that pointer. This is not a joke (even if initially, it sounds like it).

I believe that by not having a that pointer, we don’t see a lot of innovation that we could otherwise see, and we face a lot of friction that really does not need to be there. Let me explain.

In the real world, lots of entities perform services for me. For example, I can borrow a book from a number of different libraries. So when I choose one particular library to borrow a certain book from, I do the equivalent of setting the this pointer to that library, and request the service borrow from that this pointer. And that’s about all I can do.

From the library’s perspective, it gets an incoming request to borrow a certain book, but it has absolutely no idea who is making the request. And in the real world, that means the library would most certainly go out of business because it would have no way of distinguishing those people who bring books back after they borrowed them, and those who just keep them.

In other words, in the real world the library requires a that pointer as well, i.e. a pointer pointing not only to the object that is supposed to be performing the service (this), but also a pointer to the entity (that) requesting the service, such as "me".

In (pseudo) code in a Java-like language that would support that, the library borrowing code would look as follows:

 class Library { ... public borrow( Book toBorrow ) { if( that == null ) { throw MustGetLibraryCardFirstException(); } if( ! customerDatabase.isInGoodStanding( that )) { throw PayOutstandingFeesFirstException(); } ... } } 

Isn’t that much more natural than doing whatever you’d be doing to address this without a built-in that pointer? Do any of your alternatives remind you of the arguments of the conservative C crowd back then, saying "why do I need C++, I can pass a first argument called this myself"? (it sounded reasonable back then, but not any more)

But I nevertheless hear you asking: so if you think that is such a good idea, why didn’t we notice and introduced it right with the this pointer in the 80’s?

There’s a good reason: back then, both the object requesting the service and the object providing the service were entirely under our control, in the same address space, and not very likely attempting to defraud each other. But now, in the distributed, wild wild west environment of the WWW, that assumption is most patently invalid. If I set up the equivalent of the library service on my website without checking for that, I could be certain that within 24 hours, somebody somewhere would have attempted to take advantage of it and defraud me. That’s why we require registration on important websites, and logins, and passwords, so we can get a hold of who that that guy is, and deal with him appropriately.

What we don’t have on the web today is a unifying mechanism for dealing with the that object, but we need one, just like software development started stalling without the this pointer back then.

Turns out that in LID, we have those funny URL arguments all over the place:

   http://some.url/somewhere?...&clientid=http://jim.smith.name/&credtype=...&credential=...

clientid might not have been the best choice of terms, but do you recognize it? It is the that pointer. A pointer to the entity that wishes the HTTP GET service performed on the http://some.url/somewhere resource. Here it is Jim Smith, and he provided his LID URL as the that pointer to the service.

In order to recognize lying, we provide two additional arguments, by which the that object can make a credible statement (using a digital signature, for example) why it is indeed them, and not a fraudster pretending to be them. But that’s the security icing on the cake.

Admittedly, I did not realize at the beginning of LID that that we were intruding a that pointer (shame over me, because I had been joking about a that pointer for years). But now that we recognized that, you will undoubtedly see just how powerful such an authenticated that pointer is:

Using this extremely simple mechanism, we have now a way of uniformly identifying the client for any web request, HTTP GET, POST or otherwise. Everybody can implement this! And it’s useful immediately, if initially for nothing else than to replace internal unique identifiers in a user registration database with URLs. You get many other features for free: such as invoking operations on the that object … and in LID we have barely scratched the surface with what those operations could be (SSO, authenticated messaging, contact management, social networking …)

Somebody suggested to me that the that pointer should be part of the HTTP core protocol, and on technical grounds, it’s hard to disagree (political and practical is of course a different matter). But regardless how it is implemented, it just makes a lot of sense to me to start using this pattern all over the place, even if many requests have an empty that pointer because anonymity is desired. Why should it be any more complicated??

And yes, it is very REST-ful.