[Seaside] Tiny URL processing ala Seaside

Avi Bryant avi.bryant at gmail.com
Thu Feb 9 21:10:27 UTC 2006


(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:
>
>   http://www.bountifulbaby.com?tiny=100
>
>               and
>
>   http://www.bountifulbaby.com/seaside/index/birthingsupplies? 
> searchstring=1007&searchtype=items&searchall=f
>
> 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 "/seaside/index/birthingsupplies? 
> 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  
> distribution?

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.

Avi


More information about the Seaside mailing list