Re^3: Ignorant Article

Maybe Dave isn't merely claiming to be better, after all. He and friends at London.pm have spent a fair amount of time creating properly written drop-in replacements for Matt's scripts.

Your article is also mixing up many levels of things. That CGI scripts produce ugly pages is a ridiculous claim; they can send to the browser any output they wish to, just like all other dynamic webpage generation technology can. It is true that state is hard to maintain in CGI, but so is it with any other dynamic webpage generation technology because HTTP itself, the protocol on which all them have to build, is inherently stateless. (Whoever claimed cookies were the solution forgets they're conceptually the same thing as hidden fields, which by the way is exactly the same thing as encoding data in the URL at least for GET forms so your article's separate mention is redundant.)

Makeshifts last the longest.

Comment on Re^3: Ignorant Article

Replies are listed 'Best First'.
Re: Re^3: Ignorant Article by steves (Curate) on Feb 18, 2003 at 19:41 UTC
While I'd agree that conceptually cookies and hidden fields are similar -- they both offer ways to maintain state within the confines of a stateless protocol -- I would argue that they are, in fact, different enough for separate discussion. There are RFC's for cookies that make their use much more predictable than hidden fields. And they have features like expirations that you'd have to build into a hidden fields implementation. I'm not arguing that any one state mechanism is better or worse. But they are different. I've used them both for different situations. The advantage of good abstractions and wrappers is that they provide a consistent state-saving API regardless of the underlying method(s) used. This may be what Selena/Eric was referring to with J2EE. To my knowledge it only hides it all under a consistent API, but still uses cookies (usually) or hidden fields as the mechanism. I always throw those "encoded in the URL" state-saving methods into the same bucket as hidden fields, but one could argue that as another, distinct method with its own distinct merits. IMO, A really good API defaults to whatever is available so that there's no real dependency. i.e., if cookies are disabled use another method. Selena/Eric's knock on CGI may be that there is no such layering there. I'd argue that for that you pick a higher level abstraction.	[reply]

Replies are listed 'Best First'.

Re: Re^3: Ignorant Article
by steves (Curate) on Feb 18, 2003 at 19:41 UTC

While I'd agree that conceptually cookies and hidden fields are similar -- they both offer ways to maintain state within the confines of a stateless protocol -- I would argue that they are, in fact, different enough for separate discussion. There are RFC's for cookies that make their use much more predictable than hidden fields. And they have features like expirations that you'd have to build into a hidden fields implementation.

I'm not arguing that any one state mechanism is better or worse. But they are different. I've used them both for different situations. The advantage of good abstractions and wrappers is that they provide a consistent state-saving API regardless of the underlying method(s) used. This may be what Selena/Eric was referring to with J2EE. To my knowledge it only hides it all under a consistent API, but still uses cookies (usually) or hidden fields as the mechanism. I always throw those "encoded in the URL" state-saving methods into the same bucket as hidden fields, but one could argue that as another, distinct method with its own distinct merits. IMO, A really good API defaults to whatever is available so that there's no real dependency. i.e., if cookies are disabled use another method. Selena/Eric's knock on CGI may be that there is no such layering there. I'd argue that for that you pick a higher level abstraction.

[reply]