Re: [Xsltforms-support] Evaluating long calculations asynchronously in background

[Alain C. <ala...@ag...>]

Hello Mats,
> In HTML 5 there is the Web Worker object, and it should be possible to 
> leverage this to perform the calculation in a background thread 
> client-side.
XSLTForms is not yet using Web Worker but Google Chrome is already 
complaining about XMLHttpRequest being called in main thread... ;-)
>
> I guess it is possible to implement the long running calculation in a 
> javascript function that may be called via xf:load and where the 
> result is returned via call to XForms DOM API 
> (model.getInstanceDocument(), model.recalculate()...).
>
> However, it would be nice if the operation could be kept more "XFormy" 
> and as declarative as in the "non-async" example above.
>
> I'm currently considering two possible options:
>
> 1) XForms extension attribute, like so:
>
> <xf:setvalue ref="mynode" value="..." @ext:async="true"/>
>
> 2) Implementing the operation as an xf:submission, but proxying the 
> underlying XMLHttpRequest object to intercept selected submission URLs 
> and handle them client-side:
>
>     <xf:submission resource="http://client/myfunction?param1=..." 
> serialization="...".../>
>
>     and
>
> XMLHttpRequest.registerHandler("http://client/myfunction", myhandler)
>
XSLTForms supports xf:setnode as an extension. So, with both xf:setvalue 
and xf:setnode, at first glance, I prefer a 
@mode="synchronous/asynchronous" implementation (as in xf:submission).
>
> Both options seem to have their unique merits and possible usages. 
> While the second option is probably quite straight-forward to 
> implement, the second option may require some more work, like:
>
> 1) Porting XSLTForms XPath implementation, as well as some other 
> objects (XSLTTransform), to work in a Web Worker context.
I have not been working with Web Workers yet but I read that there are 
limitations like these. XSLTForms already has its own XPath engine but 
is currently using native XML engines (an independent XML engine, fully 
written in Javascript, is already in good progress!). Why do you think 
that XSLT would also be required or is just it that XSLT would be nice 
to have available too?
> 2) Finding a way to efficiently transfer relevant data (XForms 
> instances) to the Worker context
> 2) Making modifications to the relevant action implementations in 
> XSLTForms to handle asynchronous execution of the action
>
> Seems doable to me, but would be interested to hear if someone has 
> experience to tell whether that'a crazy idea or not. Obviously, would 
> be cool if such features could become native features of XSLTForms!
I will be happy to add such features in XSLTForms even if only recent 
browsers will support them!

What do you think?

--Alain