[whatwg] A thought: <a href="..." method="post">

[James Graham]

Sjoerd Visscher wrote:

> James Graham wrote:
>
>> I should have stated explicitly that when I said "marking the message 
>> as read in some way" I intended that the "some way" could be more 
>> than just changing a message's unread flag, it could be e.g. moving 
>> the message from the inbox to a "Read messages" folder. Even if the 
>> message is "just" marked as read, this can change more than the 
>> appearance of the message - it can change where in the interface it 
>> is displayed (in some sort of virtual-folder based setup), etc.   So 
>> I don't think you can dismiss this as "not really a good example of a 
>> non-idempotent action" - it clearly /is/ non-idempotent yet 
>> representing the action as a link is normal and widely understood.
>>
>
> What this shows is that marking a message read when it is retrieved is 
> a bad idea. Retrieving a message must be done with GET, so that it can 
> be cached. Setting the read state should be done seperately with POST.

But can you do it such that it will work without javascript? I consider 
distinguishing read/unread messages to be a basic enough feature that it 
should be possible to implement it without requiring client-side 
scripting. In this case, the obvious implementation would be a 
javascript function called when the message was recieved that performed 
a background POST request to update the read flag on the message. Is 
there a better way?

> Most e-mail clients only mark an item read when it's open for a few 
> seconds, it's a bonus that you can do that too.

That's really not necessary for a web-based client (at least one with 
the example UI) since every message is explicitly requested by a click 
(as I understand it, the timer solves the problem that keyboard 
navigation over a list of messages can result in message being marked 
read).

This example isn't unique in assosiating a document request with an 
implicit change in that status of that document to the user. Another 
example would be a web-based document management system which had a 
"recently viewed documents" section. Again, this could be implemented by 
POSTing a "the document is actually being viewed" notification but 
that's really complex compared to just putting the logic to update the 
recently viewed documents list in the request handling function. Better, 
perhaps, but much more complex and requiring client side code to do 
something that previously could be handled server side.

Clearly allowing lins with method="post" would help these situations 
although they would break precaching of the webapp.

Assuming that people dislike <a method="post"> and accept that not all 
state altering operations imply form controls, it might not be possible 
for HTML5 to mitigate the additional server-side complexity mandated by 
requiring that GET operations are shadowed by extra POST operations 
everytime that requesting part of a web-app has an effect on the state 
of the app. Even so, we should make it easy to implement the client side 
part of the deal, preferably in a script-free way.

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs