[Seaside] Tiny URL processing ala Seaside
nevin at bountifulbaby.com
Thu Feb 9 22:47:05 UTC 2006
Avi Bryant wrote:
> (Sorry for the delay on the reply)
> On Jan 29, 2006, at 12:56 PM, Nevin Pratt wrote:
>> Hi All!
>> I think we are all familiar with the service offered by http://
>> www.tinyurl.com, for transforming huge URL's into tiny ones. I've
>> been running a similar mechanism in my Seaside app for maybe half a
>> year now. For example, on my site, both of the following URL's do
>> the same thing:
>> If you try both of the above URL's, you will see that the URL
>> arguments "searchstring=1007&searchtype=items&searchall=f" (from the
>> second URL) are used by the Seaside component to prepopulate the
>> search panel. The URL argument "tiny=100" will cause the Seaside
>> component to reference a dictionary, where the "100" is a key, and
>> searchstring=1007&searchtype=items&searchall=f" is the value. So,
>> the 100 is transformed into the bigger URL, which in turn is then
>> looked at for arguments for populating the search panel.
>> Using a dictionary in this manner, it is trivially easy to support
>> tiny URL's.
>> Should a mechanism like this be put into the general Squeak
> This strikes me at first glance as strangely circular. The reason to
> have named arguments in the query string in the first place is to
> have bookmarks that can live longer than a single squeak image -
> otherwise you could just use the opaque session/continuation ids. So
> you're replacing an opaque identifier that indexes into an in-image
> Dictionary with meaningful, external identifiers, and then replacing
> those with a different opaque identifier that indexes into an in-
> image Dictionary? Why not just clear away all the cruft and go back
> to _s and _k, and make your sessions really long lived?
> Ok, there *is* a good answer to that, which is that sessions use a
> lot more memory than your tiny-url dict does. But it seems like we
> might be able to solve that for this purpose without going through so
> many lossy indirections.
Seaside 2.3 doesn't have _s and _k in the URL. I've just started
playing with Seaside 2.5, and if not for that, I would be totally lost
by what you mean with "go back to _s and _k". But I think I see it now.
Anyway, you mentioned "memory" as the answer to your question. Well,
the answer (for Seaside 2.3) is actually four-fold:
1. Long lived sessions eat memory very rapidly (eg, your answer).
2. Long lived sessions compound security issues.
3. Seaside 2.3 did not support bookmarkable URL's
4. Short "easy-to-remember" URL's are nicer to the customer than long
randomly encoded URL's :-)
I think the issues surrounding #1 above are relatively well-known to all
of us, so I won't dwell on it further.
The issues surrounding #2 are when one user "hijacks" another user's
session, which probably occurs most often because the first user emails
their URL to the second user, without realizing they just handed over
their session "keys to the kingdom" when they did that. Shorter
sessions reduce the risk of damage due to session hijacking.
Avi, at one time I remember you talking about explicitly tying the
session to the IP address-- was that ever done? If so, then hijacking
risk is almost completely eliminated, regardless of session lifetime.
As for issue #3, long ago I came up with a relatively simple scheme for
making a single Seaside 2.3 application have multiple entry points. For
example, the main entry point is, of course, the home page, accessed in
the usual way:
But if I instead wanted to start the application from within the
supplies section of the website, this URL could be used:
The only difference between the above two URL's, so far as Seaside is
concerned, is a difference in what component becomes the first rendered
component in the application. In either case, once the application is
begun by the user, from there it continues in the usual Seaside
fashion. Well, almost. There is still one more (subtle) difference. I
also made changes that caused Seaside to ignore (and also preserve)
anything in the URL between the "/seaside/" part of the URL and the
session gobbly-de-gook at the end at the end of the URL. Thus, with the
second URL above, the '/index/birthingsupplies' portion of the URL stays
in the URL throughout the Seaside session. This makes it so that if the
session ever expires, it faults back to the same URL as it began with,
whatever that happened to be.
At the time I did this, Seaside had a real problem with bookmarkable
URL's, and this scheme solved my need for bookmarkable URL's (the
"birthingsupplies" component of the website is only one of many, many
components that can be indexed into in this manner). I understand that
for Seaside 2.5 (and above), there have been great strides made in
bookmarkable URL's, but care to give me a pointer on how to do it?
As for issue #4, it is a no-brainer. If you want to be able to give a
customer a seamingly static URL into a Seaside application, shorter is
always better than longer. Appending "?tiny=" and then some short
number is about as short and clean as I could think of. Doesn't matter
if Seaside has to work a little harder to resolve it-- the important
thing here is something easy for our customers.
In any case, Seaside 2.5 (and above) may change my thinking on a few things.
More information about the Seaside