HTML5 deployment: progress comes into sight

[Sannyasin Brahmanathaswami]

Just getting back here after  a week away on another project where they are moving the Hinduism Today app to an HTML 5 platform

(shameless promotion) check it out… pretty cool  release (free) on the App store… Android version is buggy.

@ Roland: Right.. my use of "Syncronous" was  a bit off, more like asynchronous w/ wait  (see below)

@ HH Thank you. Your clarification is perfect, exactly our challenge, well defined.

I think the use cases are obvious: Assuming we want to

a)  "encapsulate" all the heavy lifting to "*models*.livecode" scripts that do the hard work
b) we use the browser widget as a canvas for views  small triggers.

you would want to be able to, for example have a user enter some year  (say date of birth) in a little browser widget form thing.

submit to the "model.livecode" script  and if they entered something stupid like

2620  instead of 2062

your data input validator would reply to the brower widget (which must somehow know to halt processing) and reply to the user

"Hey, No way you were born in 2620!"
-------
AND During development… let's say the user did enter 2062, it pass validation, but the model.livecode attempt to store it in the sqllite database fails because some error in your LC code… we need a feedback loop that can tell us exactly at one point in the JS execution the failure occurred.  because, who knows… maybe you passed a bad param in the JS.. 

Mark: check out my earlier business request… at the risk of starting a flame war over LC's attempts for revenues from the existing paid user base, "you all" might consider taken that dollar value quoted to me and posting is as a "reach goal"  You might find support.

BR: 

FWIW  I will copy here : this is the distillation requirements  as sent back to me, since they detail some of the difficulty faced. 

minus the $ value attached to quotation

----------
Requirements

Enhance the current browser handler feature, allowing LiveCode handlers called from JavaScript to return a value immediately to the calling code. This requires the LC handlers to be executed synchronously - the calling code will block until the LC handler completes and its value is returned.


Platforms

1)                       Android
JavaScript calls are executed on a separate thread owned by the WebView - getting a return value requires posting the handler execution request to the event queue, yielding to the engine thread, which must execute the handler and store the result in such a way that it is accessible once control is returned to the waiting WebView thread.


2)                       iOS & MacOS
May be the simplest to deal with - the handler callback is either executed on the engine thread, or may call a function to run code blocks on the engine thread. What will be required though is to modify the current scheme of posting a handler execution message on the event queue to execute the handler directly so the return value can be obtained

3)                       CEF
JavaScript calls are executed within the CEF render process, so calling LC handlers requires communicating with the main engine process. CEF provides an inter-process communication (IPC) mechanism, however it is designed only for asynchronous message sending so waiting for a return value or reply is not supported.

In order to provide synchronous execution of LC handlers, an alternative IPC mechanism will be needed that should not interfere with the existing CEF scheme. Named pipes are a good implementation candidate on both Windows and Linux, however they would need to be integrated into the event handling loops on both platforms.

4)                       Execution Restrictions (Optional)
Depending on the implementation, there may be some operations that are unsafe to call from within the executing handler. For the CEF implementation, this will almost certainly include access to browser properties that require communication with the render process. There are several other areas in the engine where certain classes of operation are prohibited, for example within a widget’s OnPaint handler any operations that use “wait” should be avoided. It may be useful then to implement a general purpose execution restrictions mechanism to throw an error in these situations rather than allow these risky operations to occur.

 
To implement items 1 to 3 the time estimate is about 14 days of work at a cost of $.... For the optional item 4 it would require another 8 days of work at …..$
 
--------------

 

On 5/31/17, 11:35 AM, "use-livecode on behalf of hh via use-livecode" <use-livecode-bounces at lists.runrev.com on behalf of use-livecode at lists.runrev.com> wrote:

    "Synchronous" means here that the callback is done in the order it appears in
    the list of js instructions, i.e. "synchronous to the instruction order".
    
    If you say in your js function
    
       instruction1;
       callback1;
       instruction2;
       callback2;
    
    then you can't control what's done first. This is the price we have
    to pay for speed (multi-threading).
    It is even possible that callback2 arrives at LC _before_ one of
           instruction1; callback1; instruction2;
    is finished.
    That's what Jonathan tries to have (successfully in some scenarios)
    by doing in the widget first
       instruction1; callback1;
    then, after getting callback1:
       instruction2; callback2;