On Mon, Dec 21, 2015 at 02:05:14PM -0500, Karl Dahlke wrote: > 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.
Agreed. It'd make sense to share that I think. I also wonder if it isn't getting to the point that it'd make sense to make common.a into something like libedbrowse.so (or libedbrowse.dll on Windows) and thus have a shared dynamic lib for the two binaries? May be not yet, but as more of the code is shared I'm starting to think this may be a nicer way to handle this. > 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. Again, that makes sense. > I'm not going to do any of this tomorrow, > just putting some thoughts out there for comment. A possible alternative is to have an initialisation command in edbrowse-js where edbrowse passes the relevant parts of the config to edbrowse-js. I also think that, in the future, we probably need a common comms layer (i.e. process) between the two for reasons of efficiency (i.e. connection re-use). I'm not sure on the implementation of that yet though. May be an edbrowse-comms process? Cheers, Adam.
signature.asc
Description: PGP signature
_______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
