On Tue, Dec 23, 2014 at 05:50:47PM -0500, Karl Dahlke wrote:
> > it'd be nicer if the alert, prompt etc functions were done as part of the
> > protocol, letting edbrowse handle user interaction I think.
> 
> Yeah I think so too, I was saving that for a future increment.

Yeah, it may be worth doing sooner than later though, if only to make debugging easier.
> > I don't see why this can't be done via ipc messages.
> 
> I may not know enough, but I don't think ipc messages play nice with
> select, looking toward the day when we must monitor
> many input streams at the same time,
> many events coming in from many sources.
> You can select on many file descriptors, as I do in my adapter and
> other programs, but I don't think you can select on 4 file
> descriptors and an ipc message queue.
> If I'm wrong, we can switch from pipes to messages in the future,
> if it makes sense to do so.
> Probably not a big difference either way.

I don't massively mind, and as for the select thing,
it kind of depends on how portable we want to be.
If we really want to be portable then no, the two don't play nice,
but on linux, according to the documentation, they will actually work together.
I'm not sure how this'd be too much of a problem though,
since each edbrowse will have it's own edbrowse-js (with associated message queue),
and each window within edbrowse (assuming we go down the process per window
route) would share the message queue to the edbrowse-js process I suspect.
We could also look at using the mq_notify function to make async operation a bit easier and avoid the need to poll the message queue descriptors.
Anyway, just thoughts on a future increment. Let's get what we have functioning first.

Cheers,
Adam.