Re: [Edbrowse-dev] One program Two processes

[Adam Thompson <arthompson1990@gmail.com>]

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

On Thu, Dec 24, 2015 at 09:29:41PM -0500, Karl Dahlke wrote:
> Well as we consider various architectures
> I always keep in the back of my head that we're a couple of volunteers in our spare time.
> (I wonder how many fulltime people work on Chrome, or Edge.)
> We may not have the resources to do it the best way.

We're resource limited in terms of developers perhaps,
but we should aim for a good design since this usually makes things easier in the long run.
I think the time this will take to get right is probably worth the effort,
particularly as we're currently progressing at a relatively fast rate.

> In fact this year has been an anomaly, with Geoff and Kevin joining us,
> and really making good progress.

It's also brought us closer to getting more websites working and we've
gained a lot of momentum as a project because of there hard work.
I think we shouldn't waste this momentum and,
although we may move incrementally, I think we need to increment in the right
direction, even if that makes the individual increments smaller than they
otherwise may be.

> > That's cool, but what if async starts taking a long time,
> > like some sort of exponential algorithm or something?
> 
> Then it takes a long time.
> It shouldn't, unless the js page is badly written, but if it does, then so be it.
> I'm not trying to be glib, just saying we don't have the time or resources
> to build a preemtive time slicing operating system in edbrowse,
> that can context switch in and out of js sessions,
> in an engine independent fashion, or even within the constraints of a fixed engine -
> I think we're just not going to have the time for that.

And I'm not suggesting for a moment that we do that.
That's why a good architecture is important,
so that the underlying operating system can handle that stuff.
What I mean is that, by using processes and threads correctly,
we can get the async stuff to run without having to manage our own,
instruction level, time slicing.

> Pieces of js run under the ospices of the engine,
> without preemption, in their particular context / window,
> and we just hope they are sane.
> On a modern computer, a js computation would have to be insane
> to last more than a millisecond, and sure it could happen,
> and if it does edbrowse might not react as well as Chrome,
> but sometimes we're trying to get it functional,
> without necessarily covering all the corner cases.

That's true, but, as I said above, I'd rather we take smaller steps towards an
architecture which can, when we have time to implement them,
handle all the corner cases rather than jump on an easier one which we then
have to rewrite in the future when we need true async stuff.
We've done that before in other areas and it's taken a while to fix those problems.
Also, there are several well established design patterns which will completely
kill edbrowse with the new synchronous http.
One of which uses a long running http request to allow a server to push
information periodically to a web page.
This currently will cause edbrowse to hang indefinitely,
which is probably not what we want. Unfortunately,
things like this are increasingly common as developpers expect AJAX to be
truely asynchronous.
I'm not saying to hold on what we've currently got, far from it,
but rather I'm saying we need to think about this when designing things.

> P.S. If my finances continue to nosedive I might have to return to the work force,
> and that's one less edbrowse developer.
> Let's hope that doesn't happen.

It'd be a shame if you have to go back to work, but if it happens it happens.
That only makes it even more important to put in the correct foundations now
rather than keep saying we don't have time to create them.

Cheers,
Adam.

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