In a comment on my earlier post on Seaside URLs, Vincent D Murphy writes
...I still have a reservation with what you say about using a session key. Why not use the HTTP headers for session keys? I still think that opaque string has no place in a URI.
If we're actually talking about session keys, this is true: it could be stored in a cookie instead of the URL. I happen to dislike this approach in general because it means you can't have two concurrent sessions with the same application from the same browser, but I can see the arguments on the other side as well, and if someone submitted a patch to Seaside that allowed you to configure an application either way, I would probably accept it.
However, there are actually two opaque IDs in a Seaside URL: as well as a session key, there's also a continuation key, and that's the interesting one that we can't do without. Why does it have to be opaque? Because the resource that it is a locator for is a suspended computation: specifically, it's a serialized copy of the actual stack frames of the application process as they were when that particular URL was generated. Try as you might, you're not going to come up with a short, meaningful representation of that; the only thing you can do is assign it a unique ID and stick it in a table somewhere. Why does it have to be in the URL? For any one session you have hundreds of them - one per page view - and if you're allowing backtracking or multiple browser windows then many of them can be active at once. For any given request, you need to know exactly which page view it came from so that you can resume the session from the right point. Cookies can't do that for you.
But the opaqueness isn't really what bothers people, or shouldn't be. Seems to me like pretty much every web app since the first database-backed CGIs has had URLs with "meaningless" primary keys stuck in them somewhere; how else are you supposed to refer to one particular object or record out of thousands like it? The difference is that in Seaside, the object being referred to is a transient one: you don't expect to keep a given continuation around forever (although you could, if you had enough disk space), whereas a key into a Customer table will probably be valid for quite a while. So this, I believe, is the crux of the matter: is it ok for URLs to refer to transient, short lived resources? To get rid of the obvious objection, let's assume these URLs are still useful even once the transient resource is gone, they're just more useful when it's still around.
For me, the answer is obvious. When an application is running, it generates thousands and thousands of transient objects: objects modelling the current state of the user interface (is that portal channel collapsed or maximized? what are the last seven things they entered into that search field?) , the current point in a workflow (exactly which path did the user follow to get to this page?), the temporary state of an uncommitted transaction, and on, and on, in endless combinations. These aren't interesting resources in the greater scope of "the web" - you would never want to link to them from an external site. But they are extremely interesting in the context of the current session, and to forbid yourself from directly referencing them is to put on a straitjacket that I have absolutely no interest in wearing. Continuations are, to me, a particularly interesting example of such resources, but the idea of using opaque URLs to reference transient session objects (rather than the session as a whole) goes back at least as far as NeXT and WebObjects, if not further.
Previous Topic
