Web devel with python. Whats the best route?

[echuck at mindspring.com]

In article <kusnmmfs6a.fsf at lasipalatsi.fi>,
  Erno Kuusela <erno-news at erno.iki.fi> wrote:
> In article <93om7l$p6s$1 at nnrp1.deja.com>, echuck at mindspring.com
writes:
> | Also, is (b) really an advantage? How often do you need to take a
URL
> | to another machine?
>
> pretty often. mail it to a friend, etc.

But then wouldn't that friend come in as "erno" instead of themselves?


> || c) making it work with search engines
> | I'm not clear on (c) and search engines. If a session is related to
a
> | specific user, doesn't that imply that:
> |  1. the searchbot gets it's own session id,
> |  2. stores the id in the URL and
> |  3. now when a user finds the URL via the search engine, they click
in
> | and are considered to be "AltaVista"?
>
> presumably the session has expired by then and the user is redirected
> to a url with a fresh session string. one can also encode the client
> address in the url and check it.

This doesn't account for the case where the session hasn't expired yet.
Also, it doesn't seem to account for remembering users. e.g.,
automatically recognizing a previous user when they visit a site after
some days have passed and the session has expired. I suppose userId
could also be encoded in the URL separate from sessionId. But that
still takes you back to the "dirty URL" problem.


> | On the contrary, using cookies gives you clean URLs like:
> |   http://host.com/docs/faq/
> | Which when clicked through a search engine will not come in with a
> | session id that is either expired or inaccurate, like
> | http://host.com/89dfgk49f/docs/faq would.
>
> this is true.
>
> | Item (d) says cookies are ugly. What's ugly about this:?
> |   Set-Cookie: use=webware;
> | Or the clean URLs described above? Session ids are for the eyes of
> | programmers, not users.
>
> cookies are an ugly kludge in http because they are logically
> part of the information needed to locate the object in the http
> request, but they are outside of the path in the request. and they
hurt
> cacheability.

They are only part of the information required to locate the object if
that's how you're using them. If the cookie simply identifies the user
for purposes of security, then this is more of an "aspect" of web
interaction rather than part of the path to the object.

Also, if the web site is really using server side session variables to
determine content, whether the session is in a URL or a cookie, then
cacheability by the client is already out the window.


> they are a pain to manage for users, who have to enable them for your
> site. which is often painful since many browsers don't provide for
> this functionality - users have to rely on a 3rd party proxy or
> somesuch to do the filtering.

I'm not clear on this part. Most users have cookies by default because
most browsers support cookies out of the box. I define "most" by the
distribution of hits and/or users, not by enumerating all the browser
products.

I get my browser stats from:

http://www.upsdell.com/BrowserNews/stat.htm


While I'm sure stats vary quite a bit from site to site, it's usually a
matter of Netscape/Mozilla vs. Explorer vs. some small percentage of
browsers (typically < 1%) that are trying to be compatible with these
two browser camps anyway.



> of course this is small potatoes in the nauseating sea of terrifying
> kludges that is the current world wide web, so most people don't care
> very much.

Well we can definitely agree on that!  :-)


> | In summary, I think cookies are both clean and convenient, if you're
> | confident your user base has them.
>
> i think we'll have to agree to disagree.

OK, but I'd be interested in your response to my notes concerning
the "pain to users" or lack thereof. I see your other points even if I
don't agree with them, but don't know where you're coming from on this
topic.


-Chuck


Sent via Deja.com
http://www.deja.com/