I don’t think we should start from a blank page; we could always create a whole new project todo that. I think we will be doing our jobs If we can focus on improving pain points and stability.
I don’t have a problem with SSL being a filter; In fact, it is the most flexible way to do it; just needs to be designed better. Not only is it overly complicated in implementation, there are several pieces of code which scream “this will probably cause a concurrent memory problem”. On Fri, Jun 22, 2018 at 8:54 AM, Emmanuel Lécharny <[email protected]> wrote: > > > Le 22/06/2018 à 14:01, Jonathan Valliere a écrit : > > At what point is the SSL going to be redesigned and anyone using it will > be > > forced to update their code? > > Sadly, we have thousands of peope using MINA as it is. > > Mina 3.0 was an effort we started a few years ago to redesign this piece > of code. > > > > > Are we going to continue to support other projects which use internal > APIs > > or variables? > > I don't think any projects are using MINA internals. The change I > reverted was a mistake I did. The local variable name made it easy to > shot you in the foot, though. > > Seems like every good idea Emmanuel had was reverted for > > reasons from “using a private event you shouldn’t” to “not wanting to add > > an empty function handler”. Is there some official policy on > compatibility? > > The policy is : "do not break the API in 'fix' versions", aka the Z in > MINA-x.y.z > > This is why I forked a 2.1.0. We can play in this branch as much as we > like. > > Although I think it would be better to keep Y versions for added > features, still keeping the API ascendant compatible, and use a X update > for breaking the API. > > I do think we should do what you suggested : > - rename the 3.0 branch to something related to a coming future version > - really start from a blank page (which is what we did with the MINA 3.0 > effort, btw). > > FTR, MINA 3.0 was expected to keep the idea of filters, but the SSL part > was not designed as a filter. Also we wanted to have MINA handling > either non-blocking IO and also blocking IO, to make it a generic > framework, instead of being a NIO framework. > > The hard part are : > - obviously find people interested in being part of the effort in the > long term > - keeping some kind of the existing MINA logic > - simplifying the existing design which is, IMHO, way too complex > - remove as much contention as we can > > > That is a lot of work... > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org > >
