Re: plans for 2017

[Gilles Chehade]

On Thu, Feb 09, 2017 at 10:48:14AM +0100, Mischa wrote:
> Hi Gilles,
> 
> Thank you for expressing your plans. Looking forward to the changes.
> Keep it coming, you are doing great things!
> 

Thanks

Also, when we've made a bit of progress, we're going to explain a bit
more where we're going with the filters, the goal is not to keep it a
secret until last day but to allow us to move forward without all the
noise that would happen from the "i'd do it differently" people ;-)

Regarding the MTA changes we now exactly what we want to do but there
is a bit of a chicken & the egg issue with the last changes that were
mentionned. The idea is that we can achieve an MTA layer implem which
is isofunctionnal to the current one with most of the complexity that
is currently taking charge of optimizing routing, reusing connections
and managing limits entirely gone. This will not only improve quality
but also allow for new features which are painful to implement today,
as they require touching a very tricky brick of code.

Regarding the later changes all I can say for now is that it is going
to imply a configuration file format change, we'll probably find ways
to retain some syntaxic sugar but we're essentially going to have the
envelope template (the accept part) decorrelated from the action (the
deliver to / relay part) which seems like an innocent change but will
have (GOOD) implications on pretty much *every* layer of the daemon.

Now i'm done with the explaining, still swamped for a few days and I
will dive back into the code.

Gilles


> > On 9 Feb 2017, at 10:44, Gilles Chehade  wrote:
> > 
> > Hello misc@,
> > 
> > It's been calm for a while due to "real-life (tm)" events that had
> > to be handled in priority as far as I'm concerned, I don't know of
> > the reasons why the others are slacking though :-)
> > 
> > I've been willing to send this mail for a while to outline some of
> > the big plans for 2017 regarding OpenSMTPD and some of the changes
> > that are planned in different parts of the daemon.
> > 
> > 
> > 
> > First of all, regarding filters, since that's the question that is
> > coming the more often:
> > 
> > Filters are neither dead or alive.
> > We have implemented an API and the mechanics to make that API work
> > and this is what people started using while we warned them not to.
> > 
> > Turns out that while implementing a specific filter I hit an issue
> > which made it clear that there was a fundamental design issue with
> > the mechanics below the API that couldn't be worked around without
> > requiring a non-trivial refactor.
> > 
> > We had a long chat with eric@ about this design issue and how this
> > could be redesigned in a way that all the work we've done is still
> > usable and we figured a way which will reuse a big part of what we
> > already did, which guarantees that we will not find a design error
> > later down the chain and which as a bonus simplifies the daemon.
> > 
> > We're going to be working towards this way but now that we have an
> > experience in how providing the code early turned into a nightmare
> > for me, we'll work in a private branch then show the diff when the
> > code is working enough that it can be part of snapshots :-)
> > 
> > 
> > 
> > Then, regarding the MTA we're going to do a pass of simplification
> > because the code has evolved into something quite complex and from
> > experience gathered in the mail industry these last few years, the
> > code can be made much more efficient while MUCH simpler.
> > 
> > 
> > 
> > Finally, there is ongoing work that's going to span over months to
> > improve some configuration structures which is going to have a lot
> > of interesting side-effects which I'm going to keep as a surprise,
> > but that are going to be impressive. I personnally look forward to
> > this more than filters given the amounts of improvements this will
> > unlock in many areas ranging from configuration, to reload, to MTA
> > and MDA.
> > 
> > 
> > Stay tuned !
> > 
> > 
> > -- 
> > Gilles Chehade
> > 
> > https://www.poolp.org  @poolpOrg
> > 
> > -- 
> > You received this mail because you are subscribed to misc@opensmtpd.org
> > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
> > 
> 
> 
> -- 
> You received this mail because you are subscribed to misc@opensmtpd.org
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
> 

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

Re: plans for 2017

[Mischa]

Hi Gilles,

Thank you for expressing your plans. Looking forward to the changes.
Keep it coming, you are doing great things!

Mischa

> On 9 Feb 2017, at 10:44, Gilles Chehade  wrote:
> 
> Hello misc@,
> 
> It's been calm for a while due to "real-life (tm)" events that had
> to be handled in priority as far as I'm concerned, I don't know of
> the reasons why the others are slacking though :-)
> 
> I've been willing to send this mail for a while to outline some of
> the big plans for 2017 regarding OpenSMTPD and some of the changes
> that are planned in different parts of the daemon.
> 
> 
> 
> First of all, regarding filters, since that's the question that is
> coming the more often:
> 
> Filters are neither dead or alive.
> We have implemented an API and the mechanics to make that API work
> and this is what people started using while we warned them not to.
> 
> Turns out that while implementing a specific filter I hit an issue
> which made it clear that there was a fundamental design issue with
> the mechanics below the API that couldn't be worked around without
> requiring a non-trivial refactor.
> 
> We had a long chat with eric@ about this design issue and how this
> could be redesigned in a way that all the work we've done is still
> usable and we figured a way which will reuse a big part of what we
> already did, which guarantees that we will not find a design error
> later down the chain and which as a bonus simplifies the daemon.
> 
> We're going to be working towards this way but now that we have an
> experience in how providing the code early turned into a nightmare
> for me, we'll work in a private branch then show the diff when the
> code is working enough that it can be part of snapshots :-)
> 
> 
> 
> Then, regarding the MTA we're going to do a pass of simplification
> because the code has evolved into something quite complex and from
> experience gathered in the mail industry these last few years, the
> code can be made much more efficient while MUCH simpler.
> 
> 
> 
> Finally, there is ongoing work that's going to span over months to
> improve some configuration structures which is going to have a lot
> of interesting side-effects which I'm going to keep as a surprise,
> but that are going to be impressive. I personnally look forward to
> this more than filters given the amounts of improvements this will
> unlock in many areas ranging from configuration, to reload, to MTA
> and MDA.
> 
> 
> Stay tuned !
> 
> 
> -- 
> Gilles Chehade
> 
> https://www.poolp.org  @poolpOrg
> 
> -- 
> You received this mail because you are subscribed to misc@opensmtpd.org
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
> 


-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org

plans for 2017

[Gilles Chehade]

Hello misc@,

It's been calm for a while due to "real-life (tm)" events that had
to be handled in priority as far as I'm concerned, I don't know of
the reasons why the others are slacking though :-)

I've been willing to send this mail for a while to outline some of
the big plans for 2017 regarding OpenSMTPD and some of the changes
that are planned in different parts of the daemon.



First of all, regarding filters, since that's the question that is
coming the more often:

Filters are neither dead or alive.
We have implemented an API and the mechanics to make that API work
and this is what people started using while we warned them not to.

Turns out that while implementing a specific filter I hit an issue
which made it clear that there was a fundamental design issue with
the mechanics below the API that couldn't be worked around without
requiring a non-trivial refactor.

We had a long chat with eric@ about this design issue and how this
could be redesigned in a way that all the work we've done is still
usable and we figured a way which will reuse a big part of what we
already did, which guarantees that we will not find a design error
later down the chain and which as a bonus simplifies the daemon.

We're going to be working towards this way but now that we have an
experience in how providing the code early turned into a nightmare
for me, we'll work in a private branch then show the diff when the
code is working enough that it can be part of snapshots :-)



Then, regarding the MTA we're going to do a pass of simplification
because the code has evolved into something quite complex and from
experience gathered in the mail industry these last few years, the
code can be made much more efficient while MUCH simpler.



Finally, there is ongoing work that's going to span over months to
improve some configuration structures which is going to have a lot
of interesting side-effects which I'm going to keep as a surprise,
but that are going to be impressive. I personnally look forward to
this more than filters given the amounts of improvements this will
unlock in many areas ranging from configuration, to reload, to MTA
and MDA.


Stay tuned !


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org