Another thought on ipc separation. If we move in increments, I thought maybe it should be the last thing we do, but now I'm thinking maybe it should be the first thing we do. Why? It puts a very clear wall around the js engine. It lives in the back end js process, and edbrowse talks to it over a pipe or whatever, and edbrowse doesn't need to know about the js engine, and if the js engine changes, in release or to another vendor, we work within the js process only, and don't have to touch the bulk of edbrowse. The js process is jsdom.cpp and jsloc.cpp, and perhaps a couple more files as we advance. This is in c++, and all the rest of edbrowse is in c, and maybe html.cpp can revert back to html.c, as it was before. The more I play with c++ the more not thrilled I am, and probably wouldn't even use it at all except every js engine uses it. All the rest of edbrowse, including curl for ftp http smtp pop3 imap etc, seems to work fine with C. So anyways, I've practically had a bouleversement on this matter. It might be worth doing a separation sooner, rather than later.
In my last email I talked about render.cpp, but I mispoke. Yes I very well would write it as render.c, in c, and it would call the js process to fetch the objects, as it traverses the tree, to produce the buffer / display. I did not mean to suggest it would mess with js objects directly, but rather, here I am at this node, what are the children, step through them, recursive, etc. Definitely part of edbrowse proper. I still like the idea of one js process managing all the js sessions for one edbrowse process. I think it's a good compromise, and lets us use the js heap effectively. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
