edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] Named Pipes
Date: Sat, 9 Jan 2016 14:26:26 +0000	[thread overview]
Message-ID: <20160109142626.GA6360@122oven.adamthompson.me.uk> (raw)
In-Reply-To: <20160009081254.eklhad@comcast.net>

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

  reply	other threads:[~2016-01-09 14:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160008145150.eklhad@comcast.net>
     [not found] ` <20160109082016.GA2925@122oven.adamthompson.me.uk>
2016-01-09 13:12   ` Karl Dahlke
2016-01-09 14:26     ` Adam Thompson [this message]
2016-01-09 16:36       ` Karl Dahlke
2016-01-17  7:34       ` Chris Brannon
2016-01-17 10:16         ` Adam Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160109142626.GA6360@122oven.adamthompson.me.uk \
    --to=arthompson1990@gmail.com \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).