Re: [Edbrowse-dev] Tasks

[Adam Thompson <arthompson1990@gmail.com>]

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

On Fri, Dec 26, 2014 at 10:17:39PM -0500, Karl Dahlke wrote:
> 1. Research into v8 or perhaps other js engines.
> Just play with it, hello world, what can it do,
> is it better or worse than moz, perhaps rewrite jseng.cpp in it if you
> really want to dive in.

Ok, this seems like something everyone can look at,
though perhaps we want to be careful with duplicated efort.
Has anyone successfully compiled anything against v8 yet?

> 2. Is there any open source that would help us with DOM?
> I thought we might steal from Chrome, which would play better with v8,
> but I don't know if any dom software can reasonably be extracted from the whole.

I think we've been down the route of "playing nicely"
with a js implementation already. I'd really like to get a proper DOM
independant of js, then plug js into such a DOM.
That changes the research perspective (at least in my mind)
to an open source html parsing library,
then writing code to convert that representation into a dynamic DOM 
alterable via js.
That also allows us to separate the parsing and rendering code which imho would be a good thing.
> 3. How does dom really work anyways?
> Is there a book or tutorial that actually tells us what we have to implement?

Yeah, the w3c have a bunch of DOM specs,
most of which assume we've already parsed the html into a tree (which people
also refer to as a DOM), hence why we need to separate the parsing and
rendering code (we've thankfully already separated the js).

> 4. Fork off a copy of edbrowse and download files in the background,
> as described in my earlier email.

Ok, I think this's already being handled.

> 5. Implement imap. A lot of people want this.
> Many more would use it for mail if it had imap,
> and curl supports imap,
> so I don't think this would be as hard as it first appears.
Unfortunately I don't use edbrowse's mail support so I can't really 
help with this.

> 6. How are we going to approach frames and iframes.
> Today I turn them into hyperlinks to the web pages,
> but *every* other browser puts all the pages together
> into oneseamless whole.
> We should probably do that too.
> Then buffers and web pages don't corresponds 1 for 1 any more.
> Lines 237 through 451 might be this page,
> and 452 to 989 that page, and so on.

Hmmm, not sure how to handle this either.
Perhaps we could load the pages, but keep them in another buffer,
with cross-buffer js support, or some sort of frame delimiters... I don't know.

> 7. What happens when javascript accesses variables in other documents.
> This can be done through frames.
> In the mozilla world, those variables are in another compartments.
> Doesn't that cause js to blow up?
> Or at least not to see those variables?
> Or is everything in firefox in one compartment,
> but that can't be right either because each compartment
> has one global window object.
> Maybe interwindow communication doesn't happen enough for us to worry about,
> and is usually done for visual effects anyways.

Yes we *do* need to worry about this.
Basically you can do all sorts of cross-compartment calls in mozjs,
I don't really know how to implement it, but I know it can be done.
Also, they have a splitwindow object to handle global and non-global window
components, but even the mozilla devs tell people this is intended as a
firefox-only feature. Again, I think we've got a very different design from
these browsers and need to think slightly differently (taking lessons from them
where we can of course).

> 8. What is ajax and jquery and all those, and how much of that
> do we have to implement?

Ajax has a w3c spec and tutorials, jquery is a library,
all be it a popular one. If we fix our DOM we'll get a bunch of jquery for
free, and if we do ajax we'll get most of the rest (we possibly need json as well).
As for how much do we need to implement;
if we want to have a browser that functions properly on the internet in a few
years then all of it.

> 9. Find the most common websites, and trace through the js, slowly and painfully,
> to see what we really need to do.
> This is market driven, the 100 most used websites,
> and make edbrowse work for those.
> Given our limited resources, we might have to proceed this way,
> rather then doing it all.

I'm not too sure about this approach.
I think at this stage we'd do better to get a cleaner,
more maintainable design and work from there.
If we make sure we keep up with bug tracking and releases then I think the top
100 websites'll appear enough on our bugs list to eventually end up fixed.
This also allows us to fix the more fundimental problems, like our DOM,
without getting distracted by trying to hack on an existing design.

> I've tried to track through js to see where edbrowse fails and why,
> and it's a terribly slow and frustrating process,
> especially if the js has been deliberately crapized.
> I think we really need to do some of this, but I rarely have the patience
> to actually do it.

Agreed, tracking through js is important,
and will become more so if we decide to revise the parsing,
rendering and js dom logic.
What we also need to get better at is turning our findings into jsrt tests.

Cheers,
Adam.

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