NetScape Cookies offer an implementation mechanism for the `statefull
dialogs' I talked about earlier, and this is a very good thing. What
is wrong with them is that better implementation mechanisms for
`statefull dialogs' are possible. Disadvantages of cookies:
1) Privacy: NetScape Cookies, especially the kind that is persistent
between sessions (using the expires=DATE part of the proposal),
greatly increase the possibilities for marketing departments to track
my actions, especially if multiple commercial sites decide to share
their logging info.
Of course, my browser could have a feature asking me whether I want to
allow a site to set any cookies. But how many browser writers would
implement such a privacy dialog, and how many users would enable it?
The point is that other mechanisms would allow `statefull dialogs'
with much less loss of privacy (for the lazy user).
2) Time to availability: Compared to adding a session-id, adding
cookie support to a browser takes considerable effort on behalf of the
browser author. If we want workable `statefull dialog' support by all
popular browsers as soon as possible, it makes more sense to
standardize the session-id solution.
One of the benefits of the cookie solution over the session-id
solution is that cookies lessen the need for server-side databases
containing session state. This would make the life of service authors
easier.
As a service author, I have found that implementing such server-side
databases is one of the least of my problems. I'd rather have the
session-id solution N months from now than have the cookie solution,
which is a tiny bit easier to use, after N+M months. If session-id is
available after N months, a library for making server-side session
databases will be available one month later anyway.
> <mike
Koen.