On Sun, Jun 14, 2015 at 11:04:21AM -0400, Karl Dahlke wrote: > It is certainly possible that some of startwindow.js will eventually > have to return to native C, > appendChild and insertBefore in particular, but only if it must. > The advantages of keeping support routines in js are so many and so > substantial > I don't even have to list them. > A 4 to 1 code reduction is just one example.
I agree that the code reduction is nice as is the fact that, so long as it's standard ECMA script we're more or less engine independant, however I'd also make the point that *some* of that code was probably down to the nature of the mozilla engine and that we need to be careful that, at the end of this, we have a compliant DOM. > You speak of the day when "we have determined which js engine to use", > as though we will know that the js engine will not need to change again. > I don't have a lot of confidence that day will ever come. > Such things are supported and then not supported. > Even if we do settle on one brand, > mozilla as an example, the next version might > have a completely different api. We've seen that before. > All other things being equal, we would want to minimize > the code that interacts with the js engine. > Call it insurance if you will. I agree, but one of my biggest problems with mozilla as a js engine is the constant, incompatible, changes in the API. That's one of the things I like with Duktape in that it's a js engine first and foremost and isn't subject to the demands of a specific browser. In addition, as we move the DOM into the js process (which'll probably have to happen at some stage), we'll find that some of this stuff becomes easier since the support code will already be written as part of putting together the tidy5 DOM (at least I expect it will... though that's down to how Chris writes the new parser logic). > As per the URL setters, these had a lot of c++ strings in them, > which is why I ran into them in the first place. > We were going to have to convert this code back to C strings > if it remained native, so I did an easier conversion, > that may stand or may not. Yes, thanks for putting in the work here, and appologies if I sound ungreatful, I'm just concerned that we don't inadvertantly lose functionality or create future problems. > Yes I agree there isn't much point in moving the document.cookie setter, > it's not that much code, it is straight C, it works, > and some of it has to be native anyways. > The other setters are equally straightforward, and can remain native. > > So ok, having removed over 1,000 lines from jseng-moz.cpp, > and having converted the remaining c++ strings to c, > Adam I think we are finally go for launch. > Create jseng-duk.c, and I hope it works, and works well, and works cleanly. > After a small amount of research, Chris is pretty optimistic. > It looks a lot easier to work with than the mozilla beast > we've been wrangling with thus far. But only time will tell. Indeed and the usage model seems to fit more neatly into ours. I'm hoping to be able to put in some real work on this this weekend. Cheers, Adam.
signature.asc
Description: Digital signature
_______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
