[Edbrowse-dev] Short Timers

[Edbrowse-dev] Short Timers

[Karl Dahlke]

If you call up www.eventbrite.com you'll notice 10 javascript timers
at the top of the page, all active in 4 milliseconds.
It occurs to me that if javascript is suppose to run in 4 ms,
it should probably just run.
Now if js is scheduled to run in 10 seconds, then it should wait on your command,
wait for you to read the page, because we read a new website slower than
our sighted friends, so long timers are under our control,
but perhaps any timer under one second, or whatever threshold we choose,
should just run.
Queue them up in order of time and run them.
Even if they do nothing other than visual effects,
at least those first ten annoying lines about js timers
would be off of the web page.
What do you think?

Karl Dahlke

Re: [Edbrowse-dev] Short Timers

[Adam Thompson]

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

On Wed, Apr 08, 2015 at 09:19:51AM -0400, Karl Dahlke wrote:
> If you call up www.eventbrite.com you'll notice 10 javascript timers
> at the top of the page, all active in 4 milliseconds.
> It occurs to me that if javascript is suppose to run in 4 ms,
> it should probably just run.
> Now if js is scheduled to run in 10 seconds, then it should wait on your command,
> wait for you to read the page, because we read a new website slower than
> our sighted friends, so long timers are under our control,
> but perhaps any timer under one second, or whatever threshold we choose,
> should just run.
> Queue them up in order of time and run them.
> Even if they do nothing other than visual effects,
> at least those first ten annoying lines about js timers
> would be off of the web page.
> What do you think?

I think, as I've always thought, that we should have a mechanism where js
timers run when js timers are scheduled to run,
irrespective of any reading speed differences you believe exist (in actual fact
I've found in some cases I read pages *faster* than sighted friends,
and don't see this as a valid argument).
In addition, given the way web 2.0 works,
we realy need to get rid of the manual timer mechanism sooner rather than later
as otherwise timing critical ajax stuff can *never* work,
since i'm very unlikely to be able to keep activating js timers at the top of 
the page in the correct order to make a form submit etc.

Cheers,
Adam.

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

Re: [Edbrowse-dev] Short Timers

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> In addition, given the way web 2.0 works,
> we realy need to get rid of the manual timer mechanism sooner rather than later
> as otherwise timing critical ajax stuff can *never* work,

The problem is a mismatch between the way edbrowse works and the way the
ajax web works.  Edbrowse is very synchronous.  The state of the program
only changes at the user's request.  Nothing really happens in the
background, *ever*.  Of course, that changed slightly with the addition
of background downloads, but edbrowse is still pretty synchronous.
This model is comfortable for some of us, including me.  If I'm
browsing a buffer, reading along, I know that the buffer isn't going to
change out from under me.  If it's going to change, it does so because I
told the program to take some action.
This is the teletype paradigm.

On the other hand, with ajax, you have all kinds of things happening in
the background.  What happens if I'm reading along in my buffer and some
javascript timer fires to update the page?  Will I end up reading at the
same place where I was?  It's even possible that the thing I was reading
no longer exists.  It's very asynchronous.  The Ajax model works well
for GUIs, because GUIs are also highly asynchronous.

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.

-- Chris

Re: [Edbrowse-dev] Short Timers

[Adam Thompson]

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

On Sat, Apr 11, 2015 at 10:44:58AM -0400, Karl Dahlke wrote:
> There is another problem with my quick&dirty approach,
> running the short timers now and then returning control to the user.
> A timer that fires in 5 milliseconds,
> that I decide to run now, may well queue up another timer that fires in 5 ms.
> Well my software might figure: it's just 5 ms away, run it now.
> It queues up another timer in 5 ms, which I run, and so on,
> and suddenly I'm in an infinite loop and the user is locked out.

Ouch, I hadn't thought of that.
> Of course in any other browser this does something 100 times a second,
> in the background, without churning the cpu, and without locking
> out the user.
> So whatever we decide, it has to be a bit smarter than just:
> run the shor ttimers now and put the long timers under user synchronous control.
> Perhaps Adam's background model or some other model.
> Anyways I'm not going to mess with these for a while,
> until we can all give it a bit more thought.

Yeah, it's going to be a large change whatever we do.
If we do go to an async approach, it'd also be kind of nice to do what most
modern browsers do and fetch things in parallel as well.
That'd speed up page load times which,
whilst not my biggest concern with edbrowse,
are starting to get overly long with some more js-heavy websites.

Cheers,
Adam.

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

Re: [Edbrowse-dev] Short Timers

[Adam Thompson]

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

On Sat, Apr 11, 2015 at 07:46:55AM -0700, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> >>
> > Or actually thinking of a design which works rather than just dismissing the
> > idea as impossible.
> 
> Sorry, I think you're picking up on my cynicism.  I assure you, I wasn't
> always this way.  I got my first net account back in 1993.  For me, that
> was something of a golden age, because everything on the Internet was
> more or less accessible.  But after '97 or so, it seems like I've had to fight
> one accessibility battle after the other, and it has worn me down.
> So yeah, I suppose I need to apologize for being as jaded as I am.

Don't worry, I'm as fed up with the modern internet as everyone else who has ever
had to battle ridiculously over-engineered sites which use AJAX instead of
normal html links to "avoid reloading"
what would be a 1 kb web page (if it wasn't for the 100 kb of js to implement
the previously mentioned mechanism).
In fact I'm so fed up I actually run a gopher server (not as well populated as I'd like) at:
gopher://gopher.adamthompson.me.uk

> > 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)
> 
> Yes, true.  What I do is run chrome with chromevox under a lightweight
> window manager.  It works for me, and I avoid the desktop environments.

I've never thought of running that particular setup,
I may look into it (though I'd rather use firefox for various reasons).

I'm also considering having some sort of mangled Linux distro (i.e.
with all the things one needs to do to get some sort of accessibility working)
running under a vm just for cases where edbrowse currently doesn't work.
That way I could keep snapshots for when updates break whatever the latest
accessibility "fixes" are for the Linux desktop.

> > 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.
> 
> That does sound workable!  I don't see any flaws in the basic concept.

Thanks. The tricky part is working out when we need to display the buffer
refresh button and when we can refresh automatically (i.e.
our current onchange handling).
We'll also need a more fully featured process management mechanism or this
entire thing is going to turn into a mess very quickly.

Cheers,
Adam.

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

Re: [Edbrowse-dev] Short Timers

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:
>>
> Or actually thinking of a design which works rather than just dismissing the
> idea as impossible.

Sorry, I think you're picking up on my cynicism.  I assure you, I wasn't
always this way.  I got my first net account back in 1993.  For me, that
was something of a golden age, because everything on the Internet was
more or less accessible.  But after '97 or so, it seems like I've had to fight
one accessibility battle after the other, and it has worn me down.
So yeah, I suppose I need to apologize for being as jaded as I am.

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

Yes, true.  What I do is run chrome with chromevox under a lightweight
window manager.  It works for me, and I avoid the desktop environments.

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

That does sound workable!  I don't see any flaws in the basic concept.

-- Chris

[Edbrowse-dev] Short Timers

[Karl Dahlke]

There is another problem with my quick&dirty approach,
running the short timers now and then returning control to the user.
A timer that fires in 5 milliseconds,
that I decide to run now, may well queue up another timer that fires in 5 ms.
Well my software might figure: it's just 5 ms away, run it now.
It queues up another timer in 5 ms, which I run, and so on,
and suddenly I'm in an infinite loop and the user is locked out.
Of course in any other browser this does something 100 times a second,
in the background, without churning the cpu, and without locking
out the user.
So whatever we decide, it has to be a bit smarter than just:
run the shor ttimers now and put the long timers under user synchronous control.
Perhaps Adam's background model or some other model.
Anyways I'm not going to mess with these for a while,
until we can all give it a bit more thought.

Karl Dahlke

Re: [Edbrowse-dev] Short Timers

[Adam Thompson]

[-- 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 --]

[Edbrowse-dev] Short Timers

[Karl Dahlke]

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.

I agree, and feel strongly about this.
Let me give a more concrete example.
A website is connected to the ticker,
and gives the price of a stock in real time.
It automatically and asynchronously updates the screen several times a minute.
The sighted user looks at that panel when he wants to,
and looks away when he is working on something else,
another window on the computer perhaps, or his cup of coffee.
He asks for the current stock price by moving his eyes.
He just "looks" at the real time display of the price.
Even if edbrowse could support this model by constantly updating
some buffer somewhere,
we have to ask for the stock price by a synchronous action,
refresh the buffer or cause the speech adapter to read the line in question.
It is at our command.
Or - do we want our adapter to be in league with edbrowse and read the stock
price every time it changes, and perhaps interrupt whatever else we were reading?
Personally, I don't want that.

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.
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.
I'm ok with that.

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.
We are blind and that is inescapably different.
edbrowse is a unique browser, partly for its synchronicity.

Karl Dahlke