The failure to fix this is beginning to interfere with library peer
reviews, never mind the operation of boost-dev in general. Much of the
email received from boost-dev lands in Spam nowadays from DKIM enforced
email addresses. We also are failing to rewrite SPF correctly.
I attach below the full headers from a mail received by Antony Polukhin who
is review managing Boost.Process right now. His job is impeded if reviews
by Boost members keep landing in Spam.
Can I ask boost-steering to please get on this already and get this fixed?
Niall
Delivered-To: antosh...@gmail.com
Received: by 10.25.205.12 with SMTP id d12csp142015lfg;
Wed, 2 Nov 2016 01:58:30 -0700 (PDT)
X-Received: by 10.36.92.14 with SMTP id q14mr1846291itb.97.1478077110428;
Wed, 02 Nov 2016 01:58:30 -0700 (PDT)
Return-Path: <boost-boun...@lists.boost.org>
Received: from wowbagger.crest.iu.edu (wowbagger.crest.iu.edu.
[129.79.39.203])
by mx.google.com with ESMTP id
7si2162397itu.59.2016.11.02.01.58.30; Wed, 02 Nov 2016 01:58:30
-0700 (PDT)
Received-SPF: neutral (google.com: 129.79.39.203 is neither permitted nor
denied by best guess record for domain of boost-boun...@lists.boost.org)
client-ip=129.79.39.203; Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify) header.i=@nedprod.com;
spf=neutral (google.com: 129.79.39.203 is neither permitted nor
denied by best guess record for domain of
boost-boun...@lists.boost.org)
smtp.mailfrom=boost-boun...@lists.boost.org; dmarc=fail
(p=QUARANTINE dis=NONE) header.from=nedprod.com
Received: by wowbagger.crest.iu.edu (Postfix, from userid 495) id
6E47F160B07; Wed,
2 Nov 2016 04:58:23 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
wowbagger.crest.iu.edu X-Spam-Level: X-Spam-Status: No, score=-1.8
required=5.0 tests=BAYES_00,DKIM_SIGNED, T_DKIM_INVALID autolearn=no
version=3.3.1 Received: from wowbagger.crest.iu.edu (localhost
[127.0.0.1]) by wowbagger.crest.iu.edu (Postfix) with ESMTP id
DCE5A160C73; Wed,
2 Nov 2016 04:58:04 -0400 (EDT)
X-Original-To: bo...@lists.boost.org
Delivered-To: bo...@lists.boost.org
Received: by wowbagger.crest.iu.edu (Postfix, from userid 495) id
71DDF160C58; Wed,
2 Nov 2016 04:58:03 -0400 (EDT)
Received: from mail.nedprod.com (europe4.nedproductions.biz
[213.251.186.177]) by wowbagger.crest.iu.edu (Postfix) with ESMTP id
A0F7415F627 for <bo...@lists.boost.org>; Wed,
2 Nov 2016 04:57:53 -0400 (EDT)
Received: from authenticated-user (mail.nedprod.com [213.251.186.177])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested) by mail.nedprod.com (Postfix) with
ESMTPSA id AD69F26786 for <bo...@lists.boost.org>; Wed,
2 Nov 2016 08:57:52 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail;
t=1478077072; bh=m0JYAuglZABUVinF4F4iPaS9jnh47//GLAwQco86kbs=;
h=From:To:Date:Subject:In-reply-to:References:From;
b=ojjB1UFkzPIFh5zEzSof15fJlGK3aHOemkqLycI829/rTboX6VCwVAWBtZw8GiHsP
QXwDEGqYvdqKCVAKJee5cMSEL11v9Q0nFyqpMFjkwHRihbqave0XnyMsIHJDBIxJKF
9TvcwmCR4Eb0BJFDcYlvyjBZBfmFmNtDuYoxkjaJG/b8eGHEi+fcaUbHgiiKQkPnzu
idptbTt4oJPrFdRgU4euW+PR77K0WABumaSpm6VdYcqe+4eSW+JxCIH90QOe0cbyOo
F2zNJsdUAVxHTXw0C/MXR1uzqRb3k5af+MdTJDsSY2eeIHd5tS1reSQwOqk4CTecfd
bS/NdpMaLq7XA== From: Niall Douglas <s_sourcefo...@nedprod.com> To:
bo...@lists.boost.org Date: Wed, 02 Nov 2016 08:57:51 -0000 MIME-Version:
1.0 Message-ID: <5819AA8F.16763.4B662C04@s_sourceforge.nedprod.com>
Priority: normal In-reply-to:
<b28c90b6-5b7e-7c53-2c6f-70c3ae159...@gmx.net> References:
<CAKqmYPaxM6UUWf4CO6CmnXYaCqk=zDcTdAtaVDmmEWxt=ls...@mail.gmail.com>,
<nvb636$4t2$1...@blaine.gmane.org>,
<b28c90b6-5b7e-7c53-2c6f-70c3ae159...@gmx.net> Content-description: Mail
message body Subject: Re: [boost] [process] Formal Review starts today, 27
October X-BeenThere: bo...@lists.boost.org X-Mailman-Version: 2.1.15
Precedence: list Reply-To: bo...@lists.boost.org List-Id: Boost
developers' mailing list <boost.lists.boost.org> List-Unsubscribe:
<http://lists.boost.org/mailman/options.cgi/boost>,
<mailto:boost-requ...@lists.boost.org?subject=unsubscribe> List-Archive:
<http://lists.boost.org/boost/> List-Post: <mailto:bo...@lists.boost.org>
List-Help: <mailto:boost-requ...@lists.boost.org?subject=help>
List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
<mailto:boost-requ...@lists.boost.org?subject=subscribe> Content-Type:
text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To:
boost-boun...@lists.boost.org Sender: Boost
<boost-boun...@lists.boost.org>
On 1 Nov 2016 at 23:57, Klemens Morgenstern wrote:
> Am 01.11.2016 um 23:48 schrieb Gavin Lambert:
> > On 1/11/2016 21:41, Niall Douglas wrote:
> >> You also don't need to use completion ports like ASIO does for async
> >> i/o on Windows which are slightly complex to use. There is a much
> >> simpler solution called alertable i/o which AFIO v2 uses which has NT
> >> dispatch for you all pending async i/o callbacks every time you sleep
> >> a thread. Examine AFIO v2's source code for ideas if you like, you
> >> can throw together an async pipe i/o multiplexed reactor with very
> >> little effort in no time because NT has already implemented an "ASIO"
> >> for you, no ASIO needed.
> >
> > Having written my own mostly-lock-free ASIO-lite based around
> > completion ports, I can confirm that they're not at all complex to
> > use. Meanwhile I shy away from alertable I/O because it's
> > thread-affine and requires remembering to always perform alertable
> > waits, both of which seem fragile to me. Still, the advantage of both
> > methods existing is that you can use whatever you feel most
> > comfortable with. :)
> >
> I guess the right approach for boost.process would be, to add support
> for boost.afio when it comes out, as it does now for boost.asio.
> Elsewise you'd just have multiple libraries doing the same thing.
AFIO should land in the peer review queue in 2019. Outcome, upon
which AFIO v2 is very heavily based (and probably would be the most
contentious part of AFIO v2's API design), should land in the peer
review queue early 2017 (I'm currently writing its tutorial at
https://ned14.github.io/boost.outcome/). AFIO v2 was designed to
understand child process handles and pipes, and its hierarchy of
class inheritances allows easy extension to implement child process
i/o support. Pull requests for that are welcome.
BTW it is the lack of user supplied i/o backends in Process which was a
big part of why I voted to reject it. The correct API design would allow
the user to supply *any* implementation of child process i/o, and Process
would not need to care what it is nor how it works. You would of course
supply a default i/o backend probably based on popen() on POSIX or
something equally simple, but the point is that you having to hard code
support for ASIO or AFIO shows how Process has the wrong API design.
My other big showstopper issue was you imposing on users your
serialisation API i.e. all that iostreams and FILE * machinery. It's
widely known that the committee would like a v2 iostreams to happen as
soon as possible as the current iostreams is so very 1992. Quite a few
people are experimenting with some very alternative designs right now,
again if Process didn't need to be hardcoded to use some serialisation
framework that would be a huge gain and in my mind the correct API design.
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
--
You received this message because you are subscribed to the Google Groups
"Boost Steering Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to boost-steering+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
