[Edbrowse-dev] Rebundle / One program # processes

[Kevin Carhart <kevin@carhart.net>]

Hi group,
To those who celebrate it, merry christmas,

Okay, here is my reply to all the messages from today.
Thank you for reviewing my code, Karl, and catching my memory oversights.
I could revise this now, but I'm inclined to wait a while, because
it sounds like you might be about to supercede it with increments
in the right direction, on a solid foundation.  And this sounded
like a good reason not to use S-JAX:

> Also, there are several well established design patterns which will
> completely kill edbrowse with the new synchronous http.

So maybe the zip of S-JAX code was predominantly a proof of
concept to get the wheels going around, and it doesn't
bother me if it goes away.  It sounds as though,
if time permits, you're about to supercede it by addressing
some of the deeper questions.  We're now in one of the deadest
weeks of the year, so are you guys likely to do a lot over
the next several days?   And if so, I'll hold off for a bit
on the S-JAX, because I think it may become a moot point.
Which is very exciting by the way!

Kevin






On Fri, 25 Dec 2015, Karl Dahlke wrote:

>> Here's what I have for the native implementation of a javascript function.
>
> Kevin I finally got round to looking at this.
>
> You should free the strings created by js_c_str() (memory leak).
> You may also have to free serverData after it is converted to a js string.
> It too is allocated.
> javatext should be initialized to null else
> the last line will seg fault when httpConnect fails.
> Not clear what happens for other error codes besides 200.
>
> That said, it's a great and simple implementation of
> a synchronous http call.
> And with my latest commits,
> it will use the proxies and agent and cookie jar in the config file.
> But it will not use transient or new cookies, like session cookies,
> that might be produced by the initial web page fetch from edbrowse,
> and it won't until we merge things together and there is but one instance of curl running.
>
> Next question is could we spin off the http in the background,
> which edbrowse indeed can do,
> and how that would fit together,
> and I'll think about that one,
> but meantime I do think some is better than none,
> and it might be worth implementing this synchronous routine,
> in 30 lines of code, so more websites work,
> and then work on the asynchronous model later.
> But that's just my opinion / philosophy,
> which is not always right.
> A website indeed could work, that didn't work before,
> but you may have to wait a few seconds for the http to return serially -
> well I'd make that tradeoff for now.
>
> anyways if you want to send me a revised function, or patch, or whatever...
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists