[Seaside] Truly Opaque URLs

[Jimmie Houchin]

Boris Popov wrote:
> Oh, I just don't buy that without a much better backing.
> 
> What about Amazon's URLs?
> 
> http://www.amazon.com/Microsoft-M59-00033-Mass-Effect/dp/B000OLXX86/ref=
> pd_bbs_sr_1?ie=UTF8&s=videogames&qid=1196443532&sr=8-1

Actually I've spent a lot of time manipulating Amazon URLs. They are
quite everything that a Seaside URL isn't supposed to be. State embedded
in a URL requiring marshalling of data from URL into the server.

> Or eBay's?
> 
> http://search.product.ebay.com/Mass-Effect_UPC_605433010413_W0QQfifptsZ1
> QQfvcsZ1453QQsoprZ53000938
> 
> Do you consider them beautiful? Or any other more or less complicated
> solution out there? Simply put, the end user could care less about the
> URL if the app does what users want.

Do I consider what beautiful? Amazon or eBays? No, absolutely not. A big
yuck! Do I consider Seaside's beautiful? No.

But I do believe a RESTful like URL preceding an opaque ID at the end,
and the shorter the opaque ID can be the better, is a reasonable and
more beautiful solution.

> Before someone brings up bookmarkability, I'll step in and warn that it
> has nothing with how URL looks :)

Absolutely.

> Now let me go back and don my fireproof suit.

Nah, we can be civil. :)

I was just tossing out an idea. It can be shot down and deemed bad,
ugly, unreasonable, unworkable, without merit or whatever. But if ideas
don't get brought up and discussed we'll never know. :)

I realize I might have a different opinion on this than most of the
Seaside fan/user base. But that's ok.

I do like elegant URLs. I know Seaside has a reason for having IDs in
its URLs. I do believe/hope they can be less ugly than they are. I do
like elegant looking things. Aesthetics matter. After all we are using
Smalltalk and not Perl. (ducks, sorry Randal. :)

Why are we embedding things in the URL that can be manipulated? I have
read messages in this list on deleting X portion of the URL to achieve
certain affects.

If we say that we don't want users to be able to do such. Then we should
eliminate such. Personally, I don't want users to manipulate variable
content in the URL. Even if it is just an ID.

I know that those of us who look at URLs and even are bold enough to
manipulate URLs are not the majority of users. But that's no reason to
keep the current URLs verses my opaque URLs. If there are reasons to
keep the current scheme verses my idea, fine. But I don't buy this one.

Thanks.

Jimmie