From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 5C34A77DC1 for ; Sat, 9 Jan 2016 05:12:07 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-05v.sys.comcast.net with comcast id 3pCS1s00626dK1R01pCvNy; Sat, 09 Jan 2016 13:12:55 +0000 Received: from eklhad ([IPv6:2601:405:4001:e487:21e:4fff:fec2:a0f1]) by resomta-ch2-01v.sys.comcast.net with comcast id 3pCu1s00L2MDcd701pCuJD; Sat, 09 Jan 2016 13:12:55 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20160008145150.eklhad@comcast.net> <20160109082016.GA2925@122oven.adamthompson.me.uk> User-Agent: edbrowse/3.6.0+ Date: Sat, 09 Jan 2016 08:12:54 -0500 Message-ID: <20160009081254.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1452345175; bh=mftb2vn8qVzZq9y6hqz5YkEQWKBL9/+WoysLE76hx7U=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=JClL6UxIsgvNsMsk+3L4Uk0JtqoUriR19sullQ1W8mCxQZdM9MRb9B4XhudtxW1C/ 1sOWhWz3E2AbtCeggHTZs4mOsNoXb/T39405wfSYQgVFdCJvmny05Y1IC/E9u0fxsv 4TWuHDr/jfhY0L7h1lMPCXuKT69/hazZV3kHsX5kq9uNiV0f7vGs0CFW4aEwTdxFcQ X9l/Uu5hIonGVgqSl3GTuRR92EolisqidmQryPuWuvLlHoiVpjMr4SOK7Ggg2jC2CI P+WJcpyqxj8mb27UOfYXIPK0FvWqI1LFV++M8ppW4JZpI698Lt4ZSCbcX8c35Jbvo/ T+MkODo+XLjzA== Subject: [Edbrowse-dev] Named Pipes X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 13:12:07 -0000 > 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