W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2006

Re: Extension methods & XMLHttpRequest

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 14 Jun 2006 16:33:18 +0200
Message-ID: <44901E2E.6050101@gmx.de>
To: David Morris <dwm@xpasc.com>
CC: ietf-http-wg@w3.org

David Morris schrieb:

> On Mon, 12 Jun 2006, Julian Reschke wrote:
>> David Morris schrieb:
>>> ...
>>> This is a specific case where the protocol design has ignored the
>>> realities of application user interaction design. I have found
>>> no alternatives to form.submit() within onload to achieving rich
>>> and smooth applications.
>>> ...
>> Now that's an interesting statement. It would be nice if you could
>> expand on this, because it would be useful to understand what kind of
>> use cases are solved using this method.
> Application Example: You have two frames where one depends on the other in
>   some fashion. If the onload for FrameA initiates the load of FrameB,
>   FrameB logic can be sure that FrameA data objects are present.
> Application Example 2: The application has a main window and a data
>   entry dialog. When the user input from the dialog is commited, the
>   main window requires a reload. The onload for the dialog window
>   initiates the refresh of the main window by calling a javascript
>   method in that windows and then closes the dialog window.
> Misc. Example: Timing web page loads in the style of www.numion.com's
> stopwatch facility requires careful coordination of loading two visible
> frames after the base frameset is loaded. Use of onload to trigger the
> next step provides that synchronization.
> Dave Morris

David, maybe I'm a bit slow, maybe there's a misunderstanding...

What I was saying is that calling an *unsafe* method such as POST upon 
"onload" is problematic. I didn't argue against "onload" in general. So 
do these use case require an unsafe action being performed 
automatically, or wouldn't GET be sufficient here?

Best regards, Julian
Received on Wednesday, 14 June 2006 14:33:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:39 UTC