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-boun...@lists.runrev.com on behalf of
use-livecode@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;
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
