> if we could come up with a native DOM that wasn't tied to an engine, > it would be even better. So where do we start?
Actually we've made more strides in this direction than you might realize. Fold all the js engine specific code into one file, currently jseng-moz.cpp. Make an api that talks to that file, currently implemented in ebjs.[ch]. Keep a lot of the DOM functionality on this side of that API, decorate.c html.c. All that was done in the past year. Remember when js engine specific code was *everywhere*? Sprinkled all over edbrowse? That's one reason the moz upgrade was so horrible. Remember how many JS AutoCompartment calls we use to have? Now there are two. And when we gathered that code together into one file it was at least twice as big as it is now, having moved much of it to the other side. So there is reason to believe we're gradually making sense of this. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
