[Edbrowse-dev] One Process

[Edbrowse-dev] One Process

[Karl Dahlke]

I really think all of edbrowse should roll back into one process.
Keep the js stuff in its own thread, with the same message interface,
but you don't need interprocess pipes just global structures and some kind of wakeup semaphore
or whatever the thread package offers.

A big advantage of the separate process was when js went down you didn't
lose all of edbrowse and your edit sessions etc,
and I get that,
but edbrowse-js is pretty stable these days.
If anything edbrowse crashes much more often than js.
So I don't think that's a big consideration any more.

On the other side, I just wrote, in the last email, about dynamic changes
like web authorization passwords
that would have to pass down via messages,
whereas one process with one address space would obviate that need.
And the config file would be read once, and so on,
but those are small, here's the big thing.
If curl is used in the js process, either directly
or through my http routines, we have two instances of curl running,
both messing with the same cookie jar.
We've written before about parallel instances of edbrowse clobbering each other's cookies.
That's why we typically run one edbrowse with lots of parallel sessions open,
one curl, one cookie jar.
But now we have no choice, two processes, two curls,
and worse still, they're hitting the same websites.
edbrowse will call the site and have a cookie set, perhaps the session cookie
that makes the rest of the sesssion work,
but the curl inside js doesn't have that cookie.
So when it makes an http request to that website
the request won't work.
In other words, we may need transient cookies common to the two instances of curl,
which there is no easy or practical way to do.
So I'm thinking pull everything back together into one process.

Believe me, we have not wasted time or energy because of the separation.
The two process design has forced an interface, an API,
between edbrowse and js, and we needed that.
I think that is responsible for the stability of js that we now enjoy.
But this can be retained,
even if we meld the two processes back together.
We keep all the messages going back and forth between threads,
the same interface.

I think the cookies, transient, and the ones in the jar,
will force us back into one process.
The logic seems inescapable and unassailable to me.
Just a matter of who wants to take it on, and when.

Karl Dahlke