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

[Mats E. <mat...@li...>]

Hi Alain,
Sounds like an interesting idea. Probably not trivial though! 
For the problem I have (long running calculations) I think it would still be necessary to be able to spawn off a dedicated thread (separate from the main execution thread) for performing the long running calculation (in order that the form is still responsive to other events), and a way to indicate that an action should be executed in a non-blocking manner is required I believe. While migrating all xpath evaluations to a (single) separate web worker might not solve the problem, the implementation of a feature for executing long running calculations in a separate worker thread would probably be simplified if the framework already dealt with web workers in some way or the other...
In any case, I am progressing with the implementation of the @mode=async attribute (working off your v595), which I hope shall work on xf:setvalue, xf:insert and maybe xf:setnode. 
The approach I am taking involves serializing the XsltForms_xpath and XsltForms_exprContext objects (including relevant references), passing them to a new Worker thread, deserializing and evaluating the expressions there, then serializing the result, returning it to the caller thread and deserializing the result there to allow completion of the setvalue/insert/setnode action. All these steps happen inside a new method on the XsltForms_xpath object called xpath_evaluate_async() which must be called by the action instead of the normal xpath_evaluate(). The new method returns a Promise. (I am currently using a 3rd party serialization library... there is another library out there called vkThread which could also be interesting to look at). For time being, I am only considering evaluating the xpath expressions in the @value, @origin and @inner/@outer attributes in this manner. Binding expressions etc will be evaluated in the main thread as they are currently. 
I realize that most likely my implementation will have some limitations (e.g. some xpath functions not supported since they have dependencies that might not be transferable, not all return types supported etc.) -- some which might be overcome with additional effort -- however I think most important use cases can be supported still with such limitations (e.g. calculating digests etc)...
I am interested to learn what you have in planning for a new XPath engine!? If the ability to evaluate expressions in web worker context is taken into account in the design, that would be great of course!
Welcome your feedback!

Mats


On Mon, 31 Aug 2015 21:18:53 +0200, Alain Couthures wrote:


  
    
  
  
    Hi Mats,

      The more I think about using a Web Worker for XSLTForms, the more
      it sounds obvious that the right solution should be to dedicate a
      Web Worker for storing/manipulating instances (XPath evaluations
      and submissions): only node lists and values are to be present in
      main thread actually!

      First, this means that source code has to be adapted in a lot of
      different locations.

      Second, my Javascript XML DOM implementation is ready for
      integration but my new XPath engine is not yet operational except
      for very simple expressions...

      What do you think of this different approach?

      --Alain

      Le 31/08/2015 07:25, Mats Eklund a écrit :Hi Alain,
        
Thanks for your feedback!
> 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).
One of the advantages I saw
              with the xf:submission + proxied XMLHttpRequest option is
              the submission-done notification event, which allows
              chaining subsequent actions. I now realize however, that a
              similar notification event is triggered by the xf:insert
              action (xforms-insert), so if the @asynchronous attribute
              could be applied on this action, the extension attribute
              approach would probably be the more interesting option.
              Furthermore, it looks like both xf:setvalue and xf:setnode
              could be replaced by an xf:insert action if the XPath 3.0
              functions fn:parse-xml() and fn:parse-xml-fragment() were
              available in XLSTForms (for use in the xf:insert/@origin
              attribute), in cases where the notification event is
              important. This seems doable as well...
> 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?
Concerning XSLTProcessor, large
          XSLT transforms can be long running so it would be nice if
          such could be run in a background thread. Furthermore, the
          transform() xpath function is already part of the XSLTForms
          core function library, and I'm thinking this entire library
          should ideally be available also in the web worker context. I see there are some javascript
          implementations of XSLTProcessors on the web (not sure if
          Saxon CE is possible to use -- I'm trying to clarify). 
By the way, which XML DOM level is required by XSLTForms'
          XPath implementation for navigating on XForms instance
          documents, do you know? So far it looks like the browsers'
          native XML DOM Parser is not available in web worker
          context...
          

                  / Mats 

------------------------------------------------------------------------------

_______________________________________________Xsltforms-support mailing lis...@li...://lists.sourceforge.net/lists/listinfo/xsltforms-support