On Sat, Jan 09, 2016 at 08:12:54AM -0500, Karl Dahlke wrote:
> > Adam writes:
> > I guess the next thing is to come up with some form of more generic message
> > structure so we can have something like:
> > sendIPCMessage()  receiveIPCMessage()
> > and may be registerIPCClient() initIPCServer()
> 
> perhaps in a new sourcefile ipc.c.

Yes definitely.

> Might I suggest this evolution.
> 
> 1. We clean up a few more bugs and stamp version 3.6.1.
> Review the change log, we have indeed done a few things since 3.6.0,
> and we might want to mark that before taking the next step.

Agreed, let's release what we have before going too far forward.

> 2. Set up communication by named pipes (or sockets or whatever)
> rather than direct point to point pipes, as Adam suggests.
> Apply this to the edbrowsse to edbrowse-js situation, which runs today.
> In other words,prove the concept without making any major changes
> in the architecture. One step at a time.
> Interesting to see how my existing js messages will fold into Adams
> view of IPC messages.

Ok, yeah, I think named pipes sound like the way to go so I suggest we build 
around that. The messages will be a bit different to the current ebjs ones and
thus will require a bit of moving things around but this should be ok.

> 3. Test this on windows to ensure portability.

Yep.

> 4. Although this may make no difference in the user experience,
> it is still worth calling this version 3.6.2.

I'm wondering if we should start work on 3.7 at this point,
hold off the release to get the major changes in.
This is going to be a big change and I'm not sure I want to have minor releases
differ quite so much when it comes to IPC.

Cheers,
Adam.