Re: [Edbrowse-dev] Short Timers

[Adam Thompson <arthompson1990@gmail.com>]

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

On Fri, Apr 10, 2015 at 11:48:17PM -0400, Karl Dahlke wrote:
> I was trying to compose my thoughts, trying to figure out how
> to express myself, but Chris explained it much better than I could.
> 
> > ...
> > So our ultimate task will be trying to smoosh the asynchronous paradigm
> > into the teletype paradigm, also known as forcing a square peg to fit a
> > round hole.

Or actually thinking of a design which works rather than just dismissing the
idea as impossible.

[snip]

> If edbrowse is so good that it supports all the websites
> out there, and all they're asynchronous behaviors, then edbrowse becomes worthless.
> I could just use chrome or firefox or whatever.

If you want to run a completely different OS or distro (see below).
> The power of edbrowse is at least in part that it is not asynchronous,
> that it is different, that it is command line,
> and I would like to keep it teletype as much as possible,
> even if there are some websites that it cannot browse,
> or upon which it does not behave in the standard or expected manner.

By some websites this translates (at least in my experience)
to a large chunk of the modern internet.
The fact is that I don't run a GUI by preference (and because Linux desktop
accessibility is fairly aweful unless you do some significant tinkering from
what I've seen) and thus I need a web browser which actually works on modern,
ajax enabled, websites from the command line.
I'd like to make edbrowse that browser,
but if other people would rather it becomes irrelevant for modern web browsing
then fair enough.
All comments asside,
I've actually got an idea which may avoid the square peg and round hole problem
by adding essentially a layer between the two which means we get to keep an
interface which is usable (no one wants the buffer to change mid way through
reading it) but keep edbrowse relevant on the modern internet.

> Continuing the stock example, the traditionally asynchronous ajax
> code that gets the latest stock price does not run,
> unless I tell it to, because I want to read the current price,
> and then it runs at my command, and the buffer updates, and I read it,
> and hear the current price, because I want to know it at that time.
> Then I might move my attention somewhere else, another buffer, another console,
> my cup of coffee, and I might come back to this site and push
> the ajax button an hour later.
> I think this is the model we should aim for.
> Obviously if a chunk of code is suppose to run in 5 milliseconds then it should just run,
> that's what started this very interesting and pivotal thread,
> but if the delay is ten seconds, it is probably doing something
> that we want synchronous control over,
> because we can't just watch that window and several others in parallel,
> as our sighted friends do.

Or it's doing some sort of polling which genuinely needs to run every 10 or so
seconds or something on the server side times out.
This is becoming increasingly common as a method of doing things in the absense
of websockets support (which I really don't want to get into implementing at the moment).
> We are blind and that is inescapably different.
> edbrowse is a unique browser, partly for its synchronicity.

Yes we're blind, but I've always hoped that edbrowse could become more than
just a project used by a small comunity of users, i.e.
relevant for sighted users who want a command line browser for whatever reason.
Tbh I've never been comfortable with all the blind-related rhetoric around the
project.

Anyway, as for the design;
basically we need to have DOM and JS in separate processes,
which can then be used to render the buffer on a user command.
There would need to be some care taken as to when we add a refresh buffer
button at the top of the page (or however the interface works)
but it will allow the buffer to be altered synchronously whilst keeping
edbrowse as a working browser.
Most of this has been done with the move to a js engine,
now we just need to move the DOM stuff out of the synchronous part of edbrowse
and make the js stuff a bit more asynchronous.
This isn't going to be an easy project but I think it's worth doing if we can get it right.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]