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] roadmap
Date: Sun, 18 Mar 2018 13:02:07 -0400	[thread overview]
Message-ID: <20180218130207.eklhad@comcast.net> (raw)

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

For your comment:

No major changes or enhancements for a week or two, test, browse, watch for bugs or strange behavior; then version 3.7.3.

Next, consider one or more of these.

Step gently into threading, use threads to manage downloads in the background.
That's a great way to test, that doesn't impact regular browsing.
Download 8 large files at once to make sure httpConnect and curl and all the software around it is threadsafe.

Then perhaps download all the javascript and css files asynchronously.
It's hard to see this saving much time, you have so much bandwidth and that's it, does it really matter if you fetch files one at a time or in parallel?
Maybe in small ways like a css server is stuck for 10 seconds but a different server feeding you the js files is still working, and you're not stuc. Unlikely, but maybe.
But the next step ...

async scripts and timers don't run asynchronously, our javascript dom will probably never be threadsafe, but they can be postponed while you interact with the page.
And they can run in the background js thread, instead of the foreground js thread.
If a timer does an xhr, and that server is slow, you're not stuck.
However, if you do anything that involves js, like pushing a button, then you're stuck,
because the background js has to finish before the foreground js can run.
Still, we'll have a much better response.

Another possibility is json support.
Nasa calls up 11 different json files via xhr, and does nothing with them as far as I can tell.
That seems unlikely.
Maybe some of these provide the sections of the web site that we're not seeing.
duktape has some inbuilt support for json, not sure how much or how to tap into it.
Make DOMParser() work, to support either javascript or json.

We've talked about a g.xyz or b.xyz command, to go to a file or browse a file with a designated plugin.
We already have pb.xyz to play the current buffer via a plugin, so there is precedent.
Not sure how much of a need there is for this though, or how easy or hard it is to do.
I'm sure it will introduce many more pathways, and we already have quite a few to keep track of.

Meantime, we're always doing find&fix.
Why doesn't this website work, what is wrong with our dom, can we fix it with a few missing methods, or handling something differently?
This has to continue because it is just as important, or maybe more important, than all the things I mentioned above.

Karl Dahlke

                 reply	other threads:[~2018-03-18 17:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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:

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

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


* 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).