Re: [Edbrowse-dev] A Great Sucking Sound from the South

[Adam Thompson <arthompson1990@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3718 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]