[whatwg] Web application issues (localization, session handling)

[Avi Bryant]

On Jun 16, 2004, at 9:32 AM, Mikko Rantalainen wrote:

> 1) OK, I can almost "solve" this one with CSS but still, why not add 
> new attribute "method" for every link that could have values "get", 
> "post", "delete" etc. That way I could, for example, add tree links, 
> that look like normal links, after a discussion forum message. Those 
> could have labels such as "Show parent", "Reply" and "Remove". The 
> user agent would be aware that the first link just displays data (and 
> could be prefetched), second modifies data and the last one destroys 
> data. UA could even default to different cursors or whatever to 
> differentiate between different types. In addition to this, we could 
> have "get-with-form-data", "post-with-form-data" (as usual) and 
> "delete-with-form-data" and the UA would send all successful form 
> controls upon link activation which would save repeating some session 
> book-keeping data in every link (usually every link must have at least 
> some session data; more about this later).

+1

Incidentally, what's the way you 'almost "solve"' it with CSS?

> 3) As per HTTP protocol, a compliant UA should NOT send any data to 
> server when user activates history action. So, I have to keep all 
> session related data on the form so that UA can keep track which data 
> belongs to which dialog. If my application stored any live session 
> data (instead of just user settings and other more or less static 
> things) on server end a single press of the back button would cause 
> the server and client to go out of sync and the whole logic would 
> collapse. Currently all links are problem because if I have 30 links 
> on a generated page, I have to repeat session data 30 times (once for 
> each link so that no data is lost once a link is activated). I cannot 
> use cookies because I want to support running multiple user accounts 
> in multiple UA instances (user1 in window1 and user2 in window2). 
> Cookies cannot fork either, see below.
>
> 4) and 5) The issue here is really a forking problem.

Although I completely agree with you about the problem (and that 
cookies are not a solution), you already point out the obvious thing to 
do:

> [1] As I think it further, I think _document_id_ is worthless because 
> even the server could generate an unique identifier for every page 
> (like getCurrentTime() for example).

In my web applications, I actually go much further: not only does the 
server generate a unique id for each page view, it also generates a 
unique id for each link, form, and input element.  This makes a whole 
bunch of headaches related to form processing simply go away.

Avi