Same as Thomas. I'm fine with either 2) or 3) Thanks, Marius
On Thu, Oct 31, 2013 at 3:21 PM, Thomas Mortagne <[email protected]> wrote: > On Thu, Oct 31, 2013 at 2:01 PM, Denis Gervalle <[email protected]> wrote: >> Hi devs, >> >> In the process of preparing signed scripts and other security improvements, >> I am currently refactoring the crypto API that suffer from being available >> during the early days of the component manager. Our objective has also >> changed, and some part will be deprecated in favor of a new more evolve API. >> >> In that process, I am wondering which kind of object we allow to go through >> our API, and I see 3 possibilities: >> >> 1) Do not use any object from either Bouncy Castle (BC), nor Java >> Cryptography API (JCA), and build our own, like BC does. This is obviously >> the most decouple solution, but it will increase the conversion between >> APIs. User that may also use BC or JCA on their own will also have to >> convert their native objects to our own, to use our API. >> >> 2) Use the JCA objects only in addition to our own. The JCA has not evolved >> since a while, and is therefore really stable. This seems to me a better >> alternative. BC provide support to use those objects, so the conversion to >> BC is easy. However, these objects are not as friendly as those of BC, so >> we may need to provide some equivalent helpers existing in BC. >> >> 3) Link us more closely with BC, and use the best alternative depending on >> the situation, either BC, JCA, or our own. This is more easy for us, and >> better for users of BC outside of our API. This will avoid having to >> duplicate some BC functionality that are already user friendly enough on >> our side, therefore limiting maintenance work as well. >> >> I am more in favor of 2) or 3), not because I am lazy, but since the >> initial API already use 2) and I prefer not to duplicate existing features >> in BC which looks to me a de-facto standard for cryptography in the >> open-source world. >> >> WDYT ? > > I also prefer 2) and 3). I will let others decide if BC is standard > enough in practice to go with 3) but I'm clearly not against it, we > are strongly tied to slf4j for example and it seems to be that BC is > quite used in Java world and clean and easy enough to extend to never > really be stuck. > >> >> -- >> Denis Gervalle >> SOFTEC sa - CEO >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
