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
pEpkey.asc
Description: application/pgp-keys
