That sucking sound you're hearing is the js process pulling in more and more of the edbrowse machinery. And that's not necessarily a bad thing.
It started with basic memory, string, and url routines, so we made a couple sourcefiles common to both processes. And the common files could remain in C. No problem. Then, Kevin discovered that innerHTML has to run right now, as a native method in js, because the very next line of js code might depend on it. So all the html parsing and decorating with js objects and the like had to be part of the js process. Course it still has to be part of edbrowse, because we want to parse and render our html even if js is not running or has failed. So more files are common: html-tidy.c and decorate.c. These all go into common.a. Do I hear more sucking sounds? Certain javascript objects send an http request and get data back. Question: must this ever happen now, wherein the next line of js depends on it? If yes, and I think this would be a yes, like innerHTML, then the http machinery has to be part of edbrowse-js. Well maybe it's just a simple curl call. Maybe we don't need to share http.c, which does so much more. We don't need ftp downloads and redirection to plugins and all those other things. But ... I fear we do need more than the curl wrapper that Kevin has put together as a test. We need the file of certificate authorities, certfile in .ebrc, and the websites that should not use certificates, and the entire proxy database to know where and when to proxy, and the user agent, and for asynchronicity in the future, the ability to fork and perform the entire http transaction in the background. If you put this altogether I think you'll agree we can't just write a little 50 line wrapper around curl, we need a good percentage of http.c. I think another file is shared. But there's more. How does it know all the certs and proxy and such? Pass that through args or environment to edbrowse-js? I don't think so. Probably the js process should read and parse the config file just like edbrowse does. Then it too would have our setup for proxy and certificates and the like. Obviously we're not going to share main.c between the two processes, so readConfigfile() would have to move to another source file that is shared, so it can be called from both processes. Course js doesn't care about mail accounts or plugins or most of what's there, but it could retain the structures that it does care about. One of these is jspool, which we now pass as an argument to edbrowse-js but wouldn't need to if it was reading .ebrc as well. I'm not going to do any of this tomorrow, just putting some thoughts out there for comment. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
