On 2006-11-08, at 10:15 EST, Matthew Cloy wrote:
Thank you for taking the time to put together such a detailed
response!
WRT the silent termination of idle functions... I would expect that
to cause a "cap" in the timing, but I tried the new code you sent
and that runs in 78ms,and if I up the loop counter 10x to 1000000
the timing is 765ms (10x as expected), so I doubt the loop is
actually being aborted in the HTML case.... I need to restart to
continue testing, so I will continue benchmarking using the
performance meters and see whether I can make more sense of the
figures I'm seeing. I'll also look at benchmarking under different
machines and different browsers as I only tested IE... I Will let
you know the results and methodology, if that would be helpful?
Yes. I (and others, I'm sure) would be interested in seeing your
results. (Perhaps this level of technical detail is more appropriate
for the [email protected] mailing list.)
I agree that the idle termination should cap the timing, so there
must be something else subtle going on here. I would love to know if
you see similar results in other browsers or not.
It is my understanding (and we have done some testing to verify) that
other than the idle cap and 'running slowly' limits, all scripts in
browsers run to completion; so I don't think there can be any
'interference' from the idle loop affecting Legal's. But, IE is
definitely a strange beast. It is the most antique of the browser
Javascripts so may have some obscure behavior we are not aware of. I
don't have IE7 installed (at this time -- waiting for my XP software
to set up a couple of Parallels VM's to test in) to test against, if
you have access to that, it would be interesting to see how that
fares in your test.
The basic advantages I'm looking to gain from legals HTML over what
we had before are:
1) Ability to use "eval" to evaluate scripts passed via XML (We are
building our view hierarchy entirely at run time, as we can't run
the servlet... for simple scripting I have implemented a basic
"javascript" compiler / interpreter in laszlo script. not the
fastest solution but good enough for "onclick"->open something type
scripts)
Keep in mind that `eval` is a prime candidate for 'injection
attacks'. You need to be very sure of your source, or to vet the
source carefully. Not sure I understand exactly what you are doing
here. Something more than what databinding can provide?
2) Ability to embed browser plugins INSIDE laszlo views. (We have a
windowing / UI system in laszlo, and a number of custom browser
plugins for displaying data, and at the moment we float the plugins
as an IFrame over/under the flash plugin.. which is rather ugly..)
In the long term, we plan to have a general embedding strategy. In
the short term, there is nothing that prevents you from extending
DHTML by making direct browser calls, just as you can extend SWF by
making direct Flash calls. Such code will be non-portable, but is
obviously useful when called for.
