RE: XForms submission: synchronous?

For some applications, it's important that the user be able to interact
with the model after submission but before submit-done|error.
For example, Kenneth Sklander and I developed a chat application (which
we have released under MPL) that uses the instance in this way.
The chat application uses an polling loop built which uses a send action
inside xforms-submit-done handler to re-fetch an instance.
Thus, there is *always* an outstanding submission, and the server can
hang as long as is necessary.
This doesn't violate the requirement that there be only one submission
at a time in progress for a submission element.
 
This same design pattern can be used to implement state mirroring, where
an instance mirrors the state of a server-side process.
We have found this mechanism to be quite valuable.
 
It seems to me that the issue of what instance data is being submitted
can be handled properly without recourse to locking.
 
 
Leigh.

 
________________________________

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of John Boyer
Sent: Thursday, June 15, 2006 9:12 AM
To: Mikko Honkala
Cc: www-forms@w3.org; www-forms-request@w3.org
Subject: Re: XForms submission: synchronous?



Hi Mikko, 

Yes, I am calling out the issue to promote discussion because I think
many of us believe it should be asynchronous so, exactly as you said,
"the spec needs to be cleared" because the asynchronous implementations
are not currently supported by it., whereas I think the intent was to
leave it open to implementers. 

Saying nothing about asynchronicity causes a step-by-step read of the
spec in which the reader never gets to the point of branching. 
The xforms:submit (or trigger with send action) begets xforms-submit
begets the entire submission all the way to done or error. 

One problem with saying nothing is that it leads to non-interoperability
of forms without strong language from us that a send action should *not*
be followed by any other actions.  The actions sequences would work on
sychronous implementations and fail on others. 

We also need to have a frank discussion of when in the submission
process do we become asynchronous.  For example, if the whole of
xforms-submit occurs on a separate thread, then we have problems if the
user is able to further interact with the form between validation and
sending the data.  Whereas, if we say that only the actual send part
goes asynchronous, then things are a lot better for us. 

Either way, the point is that not only must we say *something* along the
lines that submission MAY be asynchronous, but what we say matters, too.


John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Mikko Honkala <honkkis@tml.hut.fi> 
Sent by: www-forms-request@w3.org 

06/15/2006 02:20 AM 

To
John Boyer/CanWest/IBM@IBMCA, www-forms@w3.org 
cc
Subject
Re: XForms submission: synchronous?

	





Hi John,

I don't agree that submission is synchronous in the spec. This is a bit 
unclear in the spec, although most implementers have implemented it 
asynchronously (similar to AJAX). There is text in the spec regarding to

simultaneous ongoing submissions, which hint in the asynchronous
direction.

The xforms-submit-done is the hook for the author.

In my opinion xforms:submit does not block. It just starts the 
submission and returns immediately. That has to be cleared in the spec. 
Most browsers are event queue-based anyway, so no two actions/scripts 
are ever run simultaneously, except for ongoing submissions.

-mikko

John Boyer wrote:
>
> Current XForms 1.0 reads that submission is synchronous
> because DOMActivate on trigger "dispatches" xforms-submit.
>
> The spec does not say "(may|should|must) launch a separate
> thread to dispatch" xforms-submit.
>    
> Then, xforms-submit capture, bubble and default processing
> occur.  The default processing then describes the occurrence
> of the entire submission down to done or error.
>
> Therefore, it is currently reasonable for an XForms author to
> assume that a send action which does an instance replacement
> will actually replace the instance before the next action after
> the send occurs.
>
> To be fair, it would be *better* for that author to write the
follow-on
> actions after a send action into the xforms-submit-done handler
> in order to ensure that the follow-on actions occur only if the
> submission is successful.  And if this is done, then the resulting
> form would operate correctly whether submission is synchronous
> or asynchronous.
>
> Moreover, there's a lot of benefit to being asynchronous, and some
> implementations at least have already gone that route despite what
> the spec says, so this email is being sent to promote discussion
> about the issue so we can get alignment, either for 1.0 or 1.1.
>
> In particular, it was stated here at the FtF that the option of 
> synchronicity
> was deliberately left open so as not to preclude implementation on
> small devices.  So, clearly the language should be that a submissoin
> MAY be asynchronous.
>
> Moreover, if a submission is asynchronous, then how far into the
> process does it get while still blocking the initiating thread?  In
other
> words, is the whole dispatch of xforms-submit done by a separate
thread?
> Or do we only branch to a separate thread some time after taking a
> snapshot of the data to be submitted?   Otherwise, the sufficiently
> talented user could change the data between the point where we
> prune and validate and the point where the data is transmitted.
>
> John M. Boyer, Ph.D.
> Senior Product Architect/Research Scientist
> Co-Chair, W3C XForms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
>
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>