[Seaside] Truly Opaque URLs

[Jimmie Houchin]

Hello Ramon,

Thanks for the reply.

Ramon Leon wrote:
>> I disagree. I am not really a developer. But I care.
>> I also don't know what study has been done to determine such. 
>> In the experience of some developers on the apps they have 
>> done. That might be the case. But users silence on the issue 
>> doesn't mean that anything but silence. Voicing an opinion to 
>> Amazon, eBay, my bank or whatever wouldn't change a thing. 
>> Most people understand that and keep silent.
>> And that is regardless as to what irritates any specific user.
> 
> Users don't hang out in the Seaside mailing list, you're enough of a
> developer that aren't a user.

Guilty. Not that I would mind getting enough understanding and skill to
be a qualified developer. :)

>> I watched a video with one of the Django developers. He spoke 
>> about how often visitors to their website attempted 
>> modifications to the URLs. So they wrote code to specifically 
>> catch such instances and to understand them and provide a 
>> positive experience to their users. I am not advocating such. 
>> But just stating that the opinions expressed by many here are 
>> not the only opinions or experiences.
> 
> That's interesting, do you have a link?

Nice URL following. :)
http://video.google.com/url?docid=-3548805983075267875&esrc=sr3&ev=v&len=2317&q=django%2Bpython%2Bduration%3Along&srcurl=http%3A%2F%2Fvideo.google.com%2Fvideoplay%3Fdocid%3D-3548805983075267875&vidurl=%2Fvideoplay%3Fdocid%3D-3548805983075267875%26q%3Ddjango%2Bpython%2Bduration%253Along%26total%3D10%26start%3D0%26num%3D100%26so%3D0%26type%3Dsearch%26plindex%3D2&usg=AL29H23zF5EmS9lUcJz-fFKx8ddX8OyJGA
Which after clicking takes you to:
http://video.google.com/videoplay?docid=-3548805983075267875&q=django+python&total=25&start=0&num=100&so=0&type=search&plindex=3
Which after a little judicious snipping also works:
http://video.google.com/videoplay?docid=-3548805983075267875
I do stuff like this all the time.

This particular video didn't address what I talked about above, but does
talk about the history and philosophy of Django.

at 14:10 or so mentions beautiful URLs.
at 27:10 or so talks about URL mapping.

Okay, here I found the one I mentioned.
Short URL only. :)
http://video.google.com/videoplay?docid=-70449010942275062

At a little after 20:30 or so he talks about Django's URL philosophy and
how they handle users and 404s in order to understand how users interact
with their application.

>> I am not worried about anybody fiddling with the _s, _k, _n 
>> parameters.
>> However, I don't see any reason that they should belong in a 
>> Seaside URL. To me they seem antithetical to the "we don't 
>> need to marshall parameters" argument of Seaside. The only 
>> difference is that you don't have to think about the params 
>> or the marshalling. But somebody did at some point.
> 
> Parameters have to be marshaled, Seaside's feature is that you don't have to
> do it, the framework does it for you.  They belong in the URL because the
> URL is the only place to put them, the only question is do you munge them
> into the path, or just stick them on as parameters.  URL's are meant to have
> parameters, there is nothing unRESTful about them, so it makes sense to pass
> parameters as parameters.

Ok.

However, I don't really believe what I suggested is really messing with
the path or is harder to parse than the parameters.

Yes it was after the last / only to separate it from the base app entry,
bookmarkable, clean URL portion. Doesn't the URL have to split into its
hierachical / points anyway so that Seaside calls the correct object?

>> And then I don't believe that developers opinions or 
>> complaints about such are invalid simply because they are 
>> developers. The majority of people don't care. Fine. The 
>> majority also uses Windows. That doesn't make their opinion 
>> about OSes superior or correct.
> 
> It's not that developers opinions are invalid, it's just that we tend to
> worry about things that just don't really matter to most users.  URL's, just
> don't matter to most users, and most users are who we're writing apps for.
> More importantly, passing the key as a parameter rather than a mixing it
> with the path is no more or less ugly, but it's vastly simpler to implement
> and automate, and automating URL management is the whole point.

I won't argue one way or the other which is easier for the Seaside
developer to implement. Can't say. But I'm really not talking about
mixing anything. A short simple ID at the end.

>> Despite any other reason for my idea. Why keep the 
>> parameters? Besides that you don't have to do anything in 
>> order to keep them and you have to do something to not have them?
> 
> Do you have something simpler in mind?  What you're suggesting isn't simpler
> than parameters, it's more complex.  You want to mix a parameter into the
> path, this means I'd have to think about this every time I started playing
> with the path, or parsing the path, it'd make my job harder.  The _s and _k
> parameters don't get in my way, messing with the path however, would.  I
> much prefer named parameters over parsing paths.

I don't get where the thought that I am meaning mixing anything into the
URL. A cherry on the top of a Sundae isn't mixed into the Sundae. It was
placed in the same position as the parameters except in the example that
I used a / to separate rather than a ?

http://www.seaside.st/about/examples/multicounter?25&_k=sAuAnwVD&_n&_s=pWPgxuITuEvuGsyu
http://www.seaside.st/about/examples/multicounter/OpaqueIDHere

Does using ? make it really any easier?

http://www.seaside.st/about/examples/multicounter?a7$B!
instead of
http://www.seaside.st/about/examples/multicounter/a7$B!

>> If they weren't there already and there was just a simple 
>> short opaque id at the end. Would argue for them?
> 
> Yes, because named parameters are simpler than parsing a path.

Ok. But with my clarification above is it really the case.

Everything after the last / is UID.

>> To me legacy is the only reason for them. And that isn't the 
>> best of reasons. It is a valid reason for a season. But there 
>> is a lot of legacy code that is regularly cleaned up and 
>> removed or changed.
>
> It's not legacy, as Lukas pointed out, Seaside used to do it the way you
> suggested, the current way is the new way, and it's better.  I really just
> don't see how mixing meaningless state information into the path somehow
> makes the meaningless nature of the param more appealing.  
> 
> More to the point, I don't care about the URL being appealing, I care about
> the application actually working, and being easy to develop.  I know of no
> way to have meaningful parameter-less pretty URLs that isn't completely
> manual, so I'll choose the automated solution Seaside offers and just worry
> about solving the real problem at hand, writing applications that solve
> users problems.  I've never heard a user say his problem was that URL's
> weren't pretty enough.

True. But as I argued earlier, how many users actually provide much in
the way of input at all? (Unless its broken) Very few.

In the Django video I mentioned above. The users didn't say anything to
the developers with the exception of their behavior. The developers
inferred from the behavior what the users wanted.

Not that Seaside URLs are the biggest offenders in the world. But if
something bookmarkable, semi-readable, short, email-able, ... weren't
important we would have websites like tinyurl to permit people to do
things easily with monstrous URLs that they can't do easily otherwise.
I'm sure most of those people would really prefer to post, email or
share URLs which are real from the actual site. But they can't due to
some truly hideous beasts out there. To me that is an end user complaint
about certain ugly URLs.

Now, I know that Lukas addressed some points. But I still think we are
talking crossways at each other.

Why can't for example a 5 character Base64 UID which can represent over
1 billion combinations point to the same instance in the running Seaside
app as a certain combination of params?

ie:
a7$B!  =  ?25&_k=sAuAnwVD&_n&_s=pWPgxuITuEvuGsyu

a7$B! points to an object in the running Seaside representing the same
thing as the above parameter string.

I am not speaking as to whether or not it is technically doable or
reasonable. I don't know Seaside insides.

Lukas' speaks to cryptographically secure keys.
Why can't what I am speaking about also be a cryptographically secure key?

I am talking about not a session ID but something pointing to the exact
same thing that the current param string points to, but shorter, less
obtrusive. So I can't say that Lukas and I are speaking to exactly the
same thing. Don't know. I don't know if what he refers to in Seaside 2.0
represents what is represented here by the param string.

I don't even know what the _s, _k or the _n params point to or do.

I don't see how why my idea does is in any way less secure or more
manipulatable than what is currently done.

What my idea is that whatever is written at the end be as short as
possible, automatically generated by Seaside,
non-understandable to either Seaside Guru or newbie, ...
Something that takes nothing away from the benefits of using Seaside.
Something that doesn't make Seaside any harder to use.
And hopefully doesn't make the Seaside internals uglier.
Possible, I don't know.

In other words if yuck is necessary, as little yuck as necessary. :)

And yes, I do value something beautiful simply because it is beautiful.
Beauty is a value even if it adds no value other than beauty. :)

As I said. It was an idea. I didn't want to keep to myself if it was
reasonable to implement and added value to Seaside. Even if the value
was a more appealing URL to those of us who value such. And to those who
don't care, they still won't care. That's ok.

Any way. Thanks.

Jimmie