From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 9D72E7ABB1 for ; Sat, 11 Apr 2015 07:12:46 -0700 (PDT) Received: by widdi4 with SMTP id di4so25615625wid.0 for ; Sat, 11 Apr 2015 07:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=2RFmVByHyY2fryEAMfLyFKzQ3dTUpkKfMb1Fu9/6lNk=; b=Aw48wFgil1NzOTszEWN+5QT4aZhxnXaBBWh5VoCeKMJayOX8fTgdB9L2TWngh+X2b2 HLVMyXLJfG7AfyJNKIDKIchzojNFX8toBOExdGinni7WdXXY5qmSYlbXPhVqAGZBHOQw /YqrF8Q1/3h/MlqUS2kxK2AsFnx+eZa9TFDy3xSWEb4CZ/2NQ4M+8YQy6/jipcl0lIIA jHoxdkDMNTb4AG78WmopuiRlXTnFljcHOKzr3wj96vlgzmiZBby7VJUSezKIIt8ksV3H riDNUt2UJq+B5AEGR7Byl2x1+gpIuN/4d6dqJSgPcDITR5oI/DvGMYhG3JmbS4Yr7Pr8 yDNg== X-Received: by 10.194.221.100 with SMTP id qd4mr11396466wjc.113.1428761463292; Sat, 11 Apr 2015 07:11:03 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id dr7sm4206292wib.22.2015.04.11.07.11.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Apr 2015 07:11:02 -0700 (PDT) Date: Sat, 11 Apr 2015 15:11:00 +0100 From: Adam Thompson To: Karl Dahlke Message-ID: <20150411141100.GB9150@toaster.adamthompson.me.uk> References: <20150310234817.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy" Content-Disposition: inline In-Reply-To: <20150310234817.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] Short Timers X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 14:12:47 -0000 --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > > ... > > 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 moder= n, 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 brows= ing then fair enough. All comments asside, I've actually got an idea which may avoid the square peg and round hole pro= blem 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 co= nsole, > 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 abs= ense of websockets support (which I really don't want to get into implementing a= t 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 rea= son. 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 edbro= wse 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 c= an get it right. Cheers, Adam. --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVKSt0AAoJELZ22lNQBzHO93MIAM71rdQG+WS/8C4MGAtIMqK2 KcuBP8/wxGojyw2rLjGSratTHZ/5kfkA9S/o/ag6Hbikoj26JDKxzDSrLO80lKln Bbk7WpOGQolTyDBX+/MFRqgqIu8FZurhs1i09LhynEsg+rflsnwI9xzSA22Un6IY UBfF4TT8hYghyhMMsm2KlGuZsQvlQnQN4qcO/V7qDQrov4lxDm8tJVV7A+sQ4P6U BNYlAjEjTcc90VU/rkZYDReNVGS1Lz9C7gYkShFHcLt4nZ75O78x1NYxLVCnNHJO InnJUsRvIuLSfYT+Ib7d7KWSUUrRlu9XOrsD7CgfOQLFmZvyvoJ7rduEquVhpLA= =GW4p -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy--