Sure .. option 1 wasn't really an option, I just put it out there.
I think my last idea is quite doable, and has all the benefits of saving resources when the frames are not needed, and expanding them under the covers when they are.
It does push us towards a one process design, but I think other factors do as well.
Try as we might, it's nearly impossible to keep all the cookies in sync as two processes both fetch html pages from the same website.
98% of the time that won't matter, but when one fetch sets a cookie and the second fetch (in the other process) doesn't work properly unless that cookie is present, well, some of this we manage, like when js sets the cookie via document.cookie, but when cookies ride in on http headers through curl under the covers,
well as I say it's really hard to handle every case. This an other concerns go away with one process and one curl space, so we might be going that direction anyways.
I'm currently changing messages to simple function calls, at least for JS1, which will make it easier to do recursive and reentrant things.
This sounds easy but not quite: the messaging allows for some nice debugging because I can log each message back and forth,
without messages I have to put the same debug statements around various function calls.
And I do want the debug features as they are today, very useful.
It's not hard, just lots of details.

Karl Dahlke