[Edbrowse-dev] Where are we with AJAX and js engines?

[Edbrowse-dev] Where are we with AJAX and js engines?

[Adam Thompson]

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

Hi all,

Sorry I've been somewhat quiet as of late, been busy sorting out various things.
I was just wondering where we were re: AJAX (instead of our current synchronous
implementation) and js engines?  What's most important to fix and whos doing
what currently?

Cheers,
Adam.

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

[Edbrowse-dev] Where are we with AJAX and js engines?

[Karl Dahlke]

> What's most important and
> whos doing what currently?

I'm afraid I'm doing not a damn thing, as my mother is dying,
my wife is in a cast and even the slightest household task requires
the coordinated efforts of the two of us,
my son's emotional issues never seem to end, my daughter is flirting with
homelessness and destitution again,
dragging her son down with her,
and my wife and I will soon need to move again, as this was my Mom's house
and is underwater so the bank will glom onto it.
If any one else wants to work on edbrowse I'd be happy to direct / advise;
that's probably all I can do for the foreseeable future.

As for priority, I continue to suggest the find&fix method,
what can't people run, like google groups or github etc, why,
and is it really requiring a complex system like ajax or is it something silly
like a missing dom object?
I say that only because I tend to be user driven, market driven,
and Adam generally is not, design it all to work as it should
from the get-go, and that's good, if we all have the time.
So I don't know.
Love you all and glad you're on my team.

Ok, here's a thought.
I think the next step is separating the curl stuff out into its own curl
server process,

edbrowse --mode curl

See main.c line 550.
This would render almost no change from the user's perspective,
but would seem to be necessary for future things to work right.
I think we were talking about this when everyone went into hiatus
for various reasons.
I proposed a series of messages back and forth between user edbrowse and edbrowse curl,
to fetch data and coordinate cookies and certificates and the like.
I'll seee if I can find that thread.
One curl server per user, so that parallel instances of edbrowse
would not access and clobber the same cookie jar.
I've done this experiment: edbrowse in two different consoles,
1 reads website A, 2 reads website B,
1 exits and writes the jar, 2 exits and writes the jar,
cookies from site A are gone.
This is a big job, a necessary job,
a job that lays some ipc groundwork,
but not as big as asynchronous js and some of the other
things we're flirting with.

Karl Dahlke

Re: [Edbrowse-dev] Where are we with AJAX and js engines?

[Adam Thompson]

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

On Sat, Apr 09, 2016 at 08:27:54AM -0400, Karl Dahlke wrote:
> > What's most important and
> > whos doing what currently?
> 
> I'm afraid I'm doing not a damn thing, as my mother is dying,
> my wife is in a cast and even the slightest household task requires
> the coordinated efforts of the two of us,
> my son's emotional issues never seem to end, my daughter is flirting with
> homelessness and destitution again,
> dragging her son down with her,
> and my wife and I will soon need to move again, as this was my Mom's house
> and is underwater so the bank will glom onto it.

Sorry to hear all that.

> If any one else wants to work on edbrowse I'd be happy to direct / advise;
> that's probably all I can do for the foreseeable future.
> 
> As for priority, I continue to suggest the find&fix method,
> what can't people run, like google groups or github etc, why,
> and is it really requiring a complex system like ajax or is it something silly
> like a missing dom object?
> I say that only because I tend to be user driven, market driven,
> and Adam generally is not, design it all to work as it should
> from the get-go, and that's good, if we all have the time.
> So I don't know.

To a point I want to design things right from the get-go but if we can fix
things easily then we should.  We certainly need to continue to fix up our DOM
whatever we end up doing with our js implementation.

> Love you all and glad you're on my team.
> 
> Ok, here's a thought.
> I think the next step is separating the curl stuff out into its own curl
> server process,
> 
> edbrowse --mode curl
> 
> See main.c line 550.
> This would render almost no change from the user's perspective,
> but would seem to be necessary for future things to work right.
> I think we were talking about this when everyone went into hiatus
> for various reasons.
> I proposed a series of messages back and forth between user edbrowse and edbrowse curl,
> to fetch data and coordinate cookies and certificates and the like.
> I'll seee if I can find that thread.
> One curl server per user, so that parallel instances of edbrowse
> would not access and clobber the same cookie jar.
> I've done this experiment: edbrowse in two different consoles,
> 1 reads website A, 2 reads website B,
> 1 exits and writes the jar, 2 exits and writes the jar,
> cookies from site A are gone.
> This is a big job, a necessary job,
> a job that lays some ipc groundwork,
> but not as big as asynchronous js and some of the other
> things we're flirting with.

Agreed.  From experience with our current IPC I suggest really looking at
making it as async as possible since there are a number of instances where I
find myself having to kill edbrowse-js because it goes into some infinite loop
or something, blocking the browser.  We also need to do that in the curl process
because we need to be able to multiplex downloads in some way.

I'd quite like to look at this if I have time.  I may need a hand (Chris?) with
the details of curl_multi and curl_shared etc though.  Having said that, if
anyone wants to take it they're welcome.

Cheers,
Adam.

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

[Edbrowse-dev] AJAX and iframes

[Kevin Carhart]

I'm sorry to hear about ongoing turmoil.  Good wishes.  I hope it goes as 
well as possible.

About Adam's question, hi Adam, I have not done anything since the 
synchronous-JAX code.  I think it's all yours if you have some time.  IPC 
is over my head, or at least I don't have a background utilizing it.  But 
I have been following along interestedly with your discussions!

Since iframes have come up recently, is there anything to be gained by 
talking about the two things in tandem?  If you're considering doing some 
work on true AJAX, is there an opportunity for making some code do double 
duty and saving some work, by basing iframes on the same work as long as 
you're there?  This would be if we wanted to switch the technique from the 
current (give the user a hyperlink to that content) to inline loading of 
what the iframe contains.  I have just been reading around recently that 
iframes and AJAX are comparable, right?  I have found pages that say 
things like:

"There are basically 3 client side ways of including external content 
into a page ... a visible iframe ... a hidden iframe .... or VIA Ajax."

And a stack overflow question, "Why AJAX over iframes?" albeit from 2012.
http://stackoverflow.com/questions/10656992/why-ajax-over-iframes

thanks
Kevin