[Edbrowse-dev] socket.c and socket.h

[Edbrowse-dev] socket.c and socket.h

[Karl Dahlke]

Thinking about socket ipc for edbrowse,
I resurrected the old files, which were called tcp.c tcp.h,
but I renamed them to socket in that we will probably add udp capability.
Based on the comments in socket.c, I used these for portable sockets
between unix and windows NT. (How long ago was NT?)
I'm sure it worked at one point but who knows if it still does.
Geoff I'm copying to you because I don't know if you still monitor this mailing list.
Please have a look at these files and let me know what you think
with regard to portability and operation.
There is included a test program built by

	cc -DTEST_CONNECT socket.c -o testsock

which is in the test debug section of the makefile, so type
make testsock

Then from two different consoles

testsock l 5432
testsock c localhost 5432

l is for listen and c is for connect.

Type lines into the second and they appear at the first, until EOF.
It still works on Linux, don't know about windows.
Beyond this, Geoff, or whomever, we should add udp functions,
as Adam points out.

Or, if this is just too far off to be useful then we can delete them
and start over, but I hope it is at least a place to start.

Karl Dahlke

[Edbrowse-dev] socket.c and socket.h

[Karl Dahlke]

Hi Geoff,

I am so sorry we left you out of the loop. My fault.

For ease of distribution and other reasons,
we're trying to have one executable image that does different things
under different names.
There's lots of this in unix.
Example /bin/awk symlinked to /bin/gawk,
same program having so much overlap,
but does some slightly different things depending on argv[0],
on how it's called, whether awk or gawk.
Same for /bin/bash and /bin/sh, etc.
So we want edbrowse and edbrowse-js, but the same image,
the former still invoking the latter just like you have it.
I'm not sure the best approach here for windows,
feel free to edit cmakelists if there's any better way.

We may also have edbrowse-curl, again the same image but doing different things,
maybe others in the future.

Glad to hear sockets still works after 15 years,
though we may add udp, which was never there before.
This has some advantages for many to many communications,
many threads in this process to many threads in that one,
whereas both pipes and sockets are very much point to point.

I'll write more in a bit, and will be sure to cc you
when something is relevant.
Hope you have a great new year.

Karl Dahlke

[Edbrowse-dev] telling JS about allowXHR

[Kevin Carhart]

I was wondering how to get the allowXHR flag into javascript, and 
what is the proper moment to do it.

Could I set it on the JS window, at the top of jsRunScriptResult?
set_property_bool(cw->winobj, "allowXHR", allowXHR);

This way JS will always have the updated preference.  Javascript
can be responsible for having a try-catch or similar, so that XHR
does not run, but everything else can continue.


thanks
Kevin

[Edbrowse-dev] telling JS about allowXHR

[Karl Dahlke]

> I was wondering how to get the allowXHR flag into javascript,

Well this is a funny question, that I hadn't thought of before,
but it has some real synergy with my post about edbrowse-curl messages
back and forth.
Remember I said that somehow updating variables in edbrowse,
like, fmp fma, ftp mode active ftp mode passive,
those sorts of variables have to propagate over to the curl server
because they change its behavior.
Well here we have one, the only one so far,
that affects the behavior of js.
When toggled in edbrowse, it has to propagate
to the js engine.

I think you were suggesting a counterpart variable,
window.allowXHR$ or some such,
that edbrowse could toggle when it toggled the variable
in its own process space.
But that doesn't work because it would have to tinker with such a variable
in every open window in js, many buffers,
each with a stack of web pages.
Possible, but a bit impractical, nor does it generalize.
I suspect we need a variable update message,

update foo=bar

which we already said we need for the curl server anyways.
I'll give this some thought and put something
in place; meantime you can continue to patch the other small items.

Karl Dahlke

Re: [Edbrowse-dev] telling JS about allowXHR

[Kevin Carhart]

On Thu, 31 Dec 2015, Karl Dahlke wrote:

>> I was wondering how to get the allowXHR flag into javascript,
>
> Well this is a funny question, that I hadn't thought of before,
> but it has some real synergy with my post about edbrowse-curl messages

Yes, I wondered if this would dovetail with everything else that's going 
on.  Thanks Karl!

Kevin