> 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. 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. 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. 3. Test this on windows to ensure portability. 4. Although this may make no difference in the user experience, it is still worth calling this version 3.6.2. What say you? Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
