[Edbrowse-dev] Named Pipes

[Edbrowse-dev] Named Pipes

[Karl Dahlke]

> 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

Re: [Edbrowse-dev] Named Pipes

[Adam Thompson]

[-- 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 --]

[Edbrowse-dev] Named Pipes

[Karl Dahlke]

> 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

Re: [Edbrowse-dev] Named Pipes

[Chris Brannon]

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

Re: [Edbrowse-dev] Named Pipes

[Adam Thompson]

[-- 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 --]