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

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

[Karl Dahlke]

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

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

[Adam Thompson]

[-- 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 --]