On Wed, Dec 30, 2015 at 07:26:12AM -0500, Karl Dahlke wrote:
> > Ok, if I can I'd like to actually do some coding on edbrowse again,
> 
> That would be awesome.
> I know you have a 9 to 5 and your time is limited.
> 
> I've been able to put time in over the past year,
> tidy and dom representation and separate rendering of the page etc,
> and truly enjoyed it to be honest, but if you're ready for a turn
> I'll take a break for a bit and work on my 2 books or other things.

If we split things up appropriately we can probably both do stuff.
There are a few things we can work on in parallel and there are a few things we
probably need to get ironed out first.

> edbrowse-curl is fine, we certainly use it for more than http:
> ftp, sftp, scp, etc,
> but I think it should be the same inage doing different things,
> as we discovered with edbrowse-js.
> Seems silly at first, you don't need all that other machinery,
> but we found that more and more stuff creeps in.
> The curl server will need information in the config file, so may as well
> parse that, and url management, and stringfile.c,
> and it needs to know all about plugins, even if it doesn't run the plugin directly
> it needs to know about it, and on and on and pretty soon
> you have 40 	to 50 percent of the code so to ease
> distribution you may as well use the same image switching on argv[0].
> Like main.c line 481, and then set whichproc = 'c';
> (whichproc is e for edbrowse and j for javascript engine.)
> Just a thought - see how it plays out.

I'll have a look at how we're doing this,
I'm wondering if we actually need the exec at all or if we can fork and then
set the flag and whether that'll do.

> Anyways, I'm happy to let you drive for a bit,
> and I'll step back to avoid conflicts, I think we're pretty much
> done with our experiments, separate handles do indeed
> share everything as expected, and I found socket.c, which you and Geoff can look at,
> so I'll submit just one more patch from Kevin,
> which implements synchronous xhr,
> and then I can just be in a bug fix minor updates mode for a while.
> I'll post another message when the xhr code is in, probably later today,
> and then you can have a whack at it.

Ok, thanks.

> I may post some thoughts on messages to and from edbrowse-curl,
> if you don't mind, just to make sure we don't forget anything.
> That's probably the first step, a flow description of what kinds of
> messages / communication go back and forth.

Yeah, it'd be kind of nice to iron out some of the ipc stuff before we start
splitting up edbrowse any further. I'm not sure if this is completely possible,
but really it'd be nice to have some sort of relatively standard interface
which applies to both edbrowse-js and edbrowse-curl.
Obviously the messages are different,
but it'd be good if we could have some sort of common mechanism such that we don't
have to reinvent everything each time we need a client and server.
Any thoughts? I'm thinking of something like standardising around sockets for
IPC; I really don't think that losing packets with UDP is too much of an issue
over a loopback interface, but we can always use tcp or temp files for larger
 transfers.
Again, it'd be nice if whatever we do handles this somewhat transparently
and portably.
If we were unix only my idea would be something like posix message queues (not
the older sysv ones) with temp files for genuinely huge things,
but that's not a possibility on Windows.
Still something with similar functionality would make life easier I think.

Regards,
Adam.