edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] Frame AutoExpansion
Date: Mon, 07 Aug 2017 01:53:42 -0400	[thread overview]
Message-ID: <20170707015342.eklhad@comcast.net> (raw)
In-Reply-To: <alpine.LRH.2.03.1708061439370.24529@carhart.net>

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

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

      reply	other threads:[~2017-08-07  5:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-05 22:40 Karl Dahlke
2017-08-06 23:32 ` Kevin Carhart
2017-08-07  5:53   ` Karl Dahlke [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170707015342.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).