Truly Opaque URLs

I've had this idea for awhile but haven't gotten deep enough into
Seaside to know how reasonable it is to do.

The idea is that for everything past the app entry point url should be
opaque.

ie: no _k, _s type variables

That way there is no temptation by anyone to mess around with anything
in the URL or to even attempt to understand or decipher it.

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


http://www.seaside.st/about/examples/multicounter/OpaqueIDHere

Just wanted to toss this idea out there.

Thanks.

Jimmie
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sounds interesting because allways there is some comment about our 'strange'
urls.

But I'm seeing:
 Error: "/seaside/about/examples/multicounter/OpaqueIDHere" not found.

Cheers,

Sebastian Sastre

 
VD&_n&_s=pWPgxuITuEvuGsyu
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

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.

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

Now let me go back and don my fireproof suit.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre wrote:
> Sounds interesting because allways there is some comment about our 'strange'
> urls.
>
> But I'm seeing:
>  Error: "/seaside/about/examples/multicounter/OpaqueIDHere" not found.

Hello,

To me as long as there are &_k=, &_s=, &_n=  type elements in the URL,
people will always make an attempt to understand the URL and determine
what they can and cannot do with such URLs.

But with my idea, there is nothing understandable except that it is an
ID to the stuff after the app entry point.

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

Example URLs, do not work
http://www.seaside.st/about/examples/multicounter/OpaqueIDHere
http://www.seaside.st/about/examples/multicounter/URL_BASE64_UUUID_Here
http://www.seaside.st/about/examples/multicounter/sAuAnwVDpWPgxuITuEvuGsyu

My apologies about the above. They are merely examples to be able to
contrast to the actual URL I had on the demo site.

Could such a URL management also enable possibly a shorter URL? How long
(how many characters) does something like a BASE64 ID have to be to be
unique enough to identify the code running at that point in that image?

To me the more opaque and the shorter the opaque portion of the URL the
better. I think this can help reduce arguments against the ugly URLs in
Seaside. It won't eliminate the arguments, but if we can have RESTful
style URLs up to the opaque ID, then we can have much of the best of both.

Thoughts.

Thanks.

Jimmie

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

:P ugh..  Yeah, theys are even ugliers.

It's true that common *not yet used to rich web apps* user is just not used
to the fact that he/she don't have to bookmark nor type url's (beside a
domain) because there is no need to. But that will happen to he/she with all
new technologies not only Seaside.

        I was interpretating that Jimmie had achieved no strage urls in
Seaside. Let's concentrate again on real value.

        cheers,

Sebastian Sastre
LXX86/ref=
> pd_bbs_sr_1?ie=UTF8&s=videogames&qid=1196443532&sr=8-1
>
> Or eBay's?
>
> http://search.product.ebay.com/Mass-Effect_UPC_605433010413_W0
QQfifptsZ1
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jimmie,

Okay, no flames is good. I think the easiest way you can get traction on
this list is by modding Seaside to do what you have in mind. It's a lot
easier to poll people when we're comparing two equally workable proven
solutions, no?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
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 ideas 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
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I agree, the only people who complain about URLs are developers, no one else
gives a crap.  There's nothing wrong with Seaside's URLs, the whole point of
the framework is make you stop thinking about building URLs.  How exactly is
a meaningless key any less annoying when placed in the path instead of as a
parameter?  Don't worry about people fiddling with the _s and _k params, let
them, all they'll end up with is a lost session.

Ramon Leon
http://onsmalltalk.com 

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

This is the sort of thing developers tend to get overly concerned with,
while end users of web apps don't care.  At all.

When an average user goes to their bank's website, believe me, the question:

"I wonder what those characters in the url mean?"

doesn't even occur to him.  So long as the entry point to the app is
bookmarkable, and so long as normal things like "remember my username" work,
the rest is utterly irrelevant


----- Original Message -----
From: "Jimmie Houchin" <[hidden email]>
To: "Seaside - general discussion" <[hidden email]>
Sent: Friday, November 30, 2007 12:33 PM
Subject: Re: [Seaside] Truly Opaque URLs


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov wrote:
> Jimmie,
>
> Okay, no flames is good. I think the easiest way you can get traction on
> this list is by modding Seaside to do what you have in mind. It's a lot
> easier to poll people when we're comparing two equally workable proven
> solutions, no?

Oh absolutely. I would love to, but as of yet, my Seaside Mojo isn't
there yet. :)

I don't know enough of the guts or mechanics of Seaside to know if this
achievable yet or not. So I simply threw out the idea.

When said experience is available to me, I look into it. :)

Until then, or until someone who is able and likes the idea...

To me, not all of the good ideas come to the guys with the skills.
Sometimes the guys with the skills are sorry with ideas and thus we have
sorry software (inferior). Sometimes the great ideas come to those who
have no ability to implement them. I am not saying this is such, even
though I do like it. :)

I would however like to see this community be open to ideas from guys
who aren't able to implement them. Or else we will run the risk of
stifling creativity. If we truly want to operate as a community instead
of a group of isolated hackers who just happen to be on the same road
and occasionaly happen to benefit one another, then we have to enable
and encourage all parts of the community to do what they are able. To
contribute where they can.

Sometimes the idea person has a nutty idea. That's ok. Toss them out.
But encourage the discussion and at some point something brilliant may
result.

Thanks.

Jimmie
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> http://www.seaside.st/about/examples/multicounter/sAuAnwVDpWPgxuITuEvuGsyu

Seaside 2.0 to 2.3 (or something around that version) had the IDs in
the URL, not in parameters. See www.squeaksource.com for example. That
makes it difficult to create bookmark-able URLs.

> Could such a URL management also enable possibly a shorter URL? How long
> (how many characters) does something like a BASE64 ID have to be to be
> unique enough to identify the code running at that point in that image?

You easily number them or use any other unique string to identify
them. See the references to the WAExternalID class.

This would mean of course, that people would be even more tempted to
play with the parameters and you would loose the important security
aspects of your application. It would be ways much easier to guess the
parameters and go into a different session.

> To me the more opaque and the shorter the opaque portion of the URL the
> better. I think this can help reduce arguments against the ugly URLs in
> Seaside. It won't eliminate the arguments, but if we can have RESTful
> style URLs up to the opaque ID, then we can have much of the best of both.

I don't see a problem. You can already have that by using session
cookies. Then you only have the _k parameter remaining. In some cases
you can also get rid of _k (see www.cmsbox.ch for example), but I
don't suggest that you try that.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

I get irritated all the time about extremely short sessions on many
different websites I've visited. But I've yet to voice an opinion on
such to any of the websites that so irritate me. But that doesn't mean
it hasn't happened. And I'll wager that most everyone on this list has
such irritants in various aspects of using the web. And I would wager
most are silent with regard to such. But that doesn't mean they like it
or don't care.

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.

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.

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.

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?

If they weren't there already and there was just a simple short opaque
id at the end. Would argue for them?

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.

Jimmie
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote:
>> http://www.seaside.st/about/examples/multicounter/sAuAnwVDpWPgxuITuEvuGsyu
>
> Seaside 2.0 to 2.3 (or something around that version) had the IDs in
> the URL, not in parameters. See www.squeaksource.com for example. That
> makes it difficult to create bookmark-able URLs.

How does it make it more difficult to create bookmarkable URLs?

It seems to me that the bookmarkable portion is the
http://www.seaside.st/about/examples/multicounter/

And everything after that points to the running code in the image.

I don't understand this.

Why would a simple non-comprehensible UUID at the end of a URL make any
parameters easier to guess? Or how would it affect security. If there
are no parameters in the URL, how does this affect anything of the such?

../seaside/home/ABigBunchOfJibberish

It would seem to me that the only thing that would happen is what
currently happens, they would be redirected to the app entry point with
a new session ID in the URL.

>> To me the more opaque and the shorter the opaque portion of the URL the
>> better. I think this can help reduce arguments against the ugly URLs in
>> Seaside. It won't eliminate the arguments, but if we can have RESTful
>> style URLs up to the opaque ID, then we can have much of the best of both.
>
> I don't see a problem. You can already have that by using session
> cookies. Then you only have the _k parameter remaining. In some cases
> you can also get rid of _k (see www.cmsbox.ch for example), but I
> don't suggest that you try that.

I am not an expert, but I'll guess that we have such embedded in the URL
because cookies aren't always a viable solution. I don't know what all
problems cookies present or not. But that is another discussion.



Mini-Rant, not aimed anybody in particular.
Especially Lukas whose email this a response to.


As I've attempted to express in all of my emails. Quite possibly poorly.

This is simply an idea that I thought might present a cleaner URL for
Seaside while maintaining all the benefits Seaside has. That is all.

I wasn't and am not declaring any major problem per se. I just
didn't/don't see the benefit of having stated, declared or known
parameters in the URL, beyond an ID which can take you back to the point
in the code you were operating upon.

It was a thought, an idea. Not an expression of a problem.

People regularly comment about ugly Seaside URLs. Yes, they are
developers. Who else do we expect to make comments on a developers list.

I've seen numerous posts here about how users don't care about URLs and
that URLs don't matter, etc. All in defense of a particular URL scheme.
Doesn't make sense to me. Oh well.

Mini-Rant over.

My apologies to all. I guess I just don't get it.

Jimmie
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Seaside 2.0 to 2.3 (or something around that version) had the IDs in
> > the URL, not in parameters. See www.squeaksource.com for example. That
> > makes it difficult to create bookmark-able URLs.
>
> How does it make it more difficult to create bookmarkable URLs?

Because it makes it more difficult to differentiate custom URL parts
and automatic generated ones. Moreover it makes it impossible to use
relative URLs.

> And everything after that points to the running code in the image.

Well, these are just objects that are referenced. _s references an
instance of WASession. _k references an object that responds to
#value:.

> > You easily number them or use any other unique string to identify
> > them. See the references to the WAExternalID class.
> >
> > This would mean of course, that people would be even more tempted to
> > play with the parameters and you would loose the important security
> > aspects of your application. It would be ways much easier to guess the
> > parameters and go into a different session.
>
> I don't understand this.

_s and _k are cryptographically secure keys into a particular point of
a session. If you shorten these keys or use a deterministic way to
generate them, people will be able to guess the parameters and
potentially kidnap a session.

> It would seem to me that the only thing that would happen is what
> currently happens, they would be redirected to the app entry point with
> a new session ID in the URL.

Yes, this was the way it was implemented in Seaside 2.0. See
www.squeaksource.com.

> I am not an expert, but I'll guess that we have such embedded in the URL
> because cookies aren't always a viable solution. I don't know what all
> problems cookies present or not. But that is another discussion.

Seaside falls-back to normal behavior (and _s parameter in the URL) if
cookies are disabled on the client.

> My apologies to all. I guess I just don't get it.

I think I get it.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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.

> 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?

> 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.

> 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.

> 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.

> 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.

> 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.
>
> Jimmie

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.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Nov 30, 2007 7:28 PM, Lukas Renggli <[hidden email]> wrote:
> ...
> Seaside falls-back to normal behavior (and _s parameter in the URL) if
> cookies are disabled on the client.
> ...

Hi Lukas,
Isn't the default behaviour to use the _s parameter rather than a
session cookie? That's what I'm seeing on my installation, and
WASessionConfiguration>>useSessionCookie returns false .

Changing that to true makes the URLs a bit prettier (not that I'm
interested in re-opening that particular can of worms), and falls back
happily when the browser refuses cookies.

Are there any problems that I should be aware of in making that the default?

Michael
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hello Ramon,

Thanks for the reply.

Ramon Leon wrote:
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.

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?

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.

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.

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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Isn't the default behaviour to use the _s parameter rather than a
> session cookie? That's what I'm seeing on my installation, and
> WASessionConfiguration>>useSessionCookie returns false .

Sorry, I was probably unclear.

Cookies are disabled in the application configuration by default.

If cookies are enabled in the application, but the web browser doesn't
support cookies Seaside falls-back to URL parameters in this
particular session.

> Are there any problems that I should be aware of in making that the default?

Well, copying URLs around won't work. I find this especially useful
while developing the application to test in different browsers.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jimmie Houchin wrote:
If you don't like the _s _k params in your URL, can't you just turn on
cookies instead?
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jimmie Houchin wrote:
Well, I suspect you are like me:  what my old boss called a "tweaker",
i.e. someone who is always tweaking something trying to make every
aspect perfect.  This is something one has to learn to control because
the fact is, when you're in tweaking mode you are almost certainly
working on something no one else in the world notices or cares about.

In my case, I looked at how to get rid of those ugly strings, but I know
it doesn't matter so I limited my time to 5 minutes. I can click the
"use cookies" button and it works fine, if not ok.  What is important to
me is having bookmarkable URLs, but Seaside provides an effective way to
do that.

I've never heard of one single person going "ew!  Look at those URL's,
I'm never looking at this site again!".  And I don't mean that to
belittle your comments in any way, just try to help put them in
perspective. :)
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside