* [Edbrowse-dev] Named Pipes [not found] ` <20160109082016.GA2925@122oven.adamthompson.me.uk> @ 2016-01-09 13:12 ` Karl Dahlke 2016-01-09 14:26 ` Adam Thompson 0 siblings, 1 reply; 5+ messages in thread From: Karl Dahlke @ 2016-01-09 13:12 UTC (permalink / raw) To: Edbrowse-dev > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Edbrowse-dev] Named Pipes 2016-01-09 13:12 ` [Edbrowse-dev] Named Pipes Karl Dahlke @ 2016-01-09 14:26 ` Adam Thompson 2016-01-09 16:36 ` Karl Dahlke 2016-01-17 7:34 ` Chris Brannon 0 siblings, 2 replies; 5+ messages in thread From: Adam Thompson @ 2016-01-09 14:26 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 1749 bytes --] 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. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Edbrowse-dev] Named Pipes 2016-01-09 14:26 ` Adam Thompson @ 2016-01-09 16:36 ` Karl Dahlke 2016-01-17 7:34 ` Chris Brannon 1 sibling, 0 replies; 5+ messages in thread From: Karl Dahlke @ 2016-01-09 16:36 UTC (permalink / raw) To: Edbrowse-dev > I'm wondering if we should start work on 3.7 at this point, Well I'll let you and Chris manage version numbers, I don't have strong feelings about that. Karl Dahlke ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Edbrowse-dev] Named Pipes 2016-01-09 14:26 ` Adam Thompson 2016-01-09 16:36 ` Karl Dahlke @ 2016-01-17 7:34 ` Chris Brannon 2016-01-17 10:16 ` Adam Thompson 1 sibling, 1 reply; 5+ messages in thread From: Chris Brannon @ 2016-01-17 7:34 UTC (permalink / raw) To: Edbrowse-dev Adam Thompson <arthompson1990@gmail.com> writes: > 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. Really it shouldn't be a user-visible change. It shouldn't break your build, and it shouldn't break backward compatibility. So I'd say stick with putting it in a minor version number. Remember how big 3.6.0 was? But let's get past named pipes and IPC. Once we have them in, working, and well-tested, we can decide which version we want to put out next, or whether we want to keep going and try to add more features. We're good to go for a 3.6.1 though, I believe. Just give the word. -- Chris ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Edbrowse-dev] Named Pipes 2016-01-17 7:34 ` Chris Brannon @ 2016-01-17 10:16 ` Adam Thompson 0 siblings, 0 replies; 5+ messages in thread From: Adam Thompson @ 2016-01-17 10:16 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 1986 bytes --] On Sat, Jan 16, 2016 at 11:34:37PM -0800, Chris Brannon wrote: > Adam Thompson <arthompson1990@gmail.com> writes: > > > 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. > > Really it shouldn't be a user-visible change. It shouldn't break your > build, and it shouldn't break backward compatibility. So I'd say stick > with putting it in a minor version number. Remember how big 3.6.0 was? > But let's get past named pipes and IPC. Once we have them in, working, > and well-tested, we can decide which version we want to put out next, or > whether we want to keep going and try to add more features. Shouldn't and won't are two very different words. In addition, I'd like to make the edbrowse-curl change prior to the next major release and don't particularly see the point in having a large IPC change in a minor release with no user-visible changes. I think we're better off getting the architecture right and tested then going for 3.7. > We're good to go for a 3.6.1 though, I believe. > Just give the word. Ok, given that Karl's object changes are in I say go for it. I also wonder, from a version control perspective, if it's worth then making a 3.6 branch where we can make bug fixes whilst playing with IPC stuff on Master? We should be able to merge or port these changes across but this will allow us to keep up with security and bug fixes whilst we make major, non-release-ready, changes to the development code. May be we focus on getting some of the object stuff working in the 3.6 minor releases and generally fixing that side of things and keep the IPC stuff etc for 3.7? My aim with these proposals is to increase the speed at which bug fixes can be released whilst allowing the big changes to happen concurrently. Cheers, Adam. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-17 10:18 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20160008145150.eklhad@comcast.net> [not found] ` <20160109082016.GA2925@122oven.adamthompson.me.uk> 2016-01-09 13:12 ` [Edbrowse-dev] Named Pipes Karl Dahlke 2016-01-09 14:26 ` Adam Thompson 2016-01-09 16:36 ` Karl Dahlke 2016-01-17 7:34 ` Chris Brannon 2016-01-17 10:16 ` Adam Thompson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).