>> Rather than trying to implement 100% of a specific standard, >> we wanted to provide simplified APIs that would make sense >> in most use cases. However, what's implemented will always >> be to specification. > > So this only works if the standard permits a subset implementation?
That is correct. Most standards do, though. In my experience, even if a functionality is listed as a MUST, there aren't necessarily any implementations of it. We'd just have to use common sense in what order to choose what do implement. >> ... >> There are a number of Java Community Process JSR's in various stages >> of development. These JSR APIs will probably end up in ASF projects, >> some sooner than later. > >So would the TSIK be implementing these capabilities and then be leveraged >by other API providing projects? Or is the primary issue here that: > >> The JSR APIs often strive to completely implement each specification. >> While this is sometimes valuable, few applications use more than the >> most common functions. Again, TSIK is designed to simplify security >> usage as much as possible. > >And therefore, the TSIK would not be the implementation, but would be a >simplified API on top of a fuller implementation? I see it as a phasing over time, where TSIK will initially be both the implementation and the simplified APIs. Once the JSR APIs come in play, these TSIK APIs should be able to be implemented on top of the JSR implementation, which may or may not be in TSIK. I realize that it may sound a bit vague, but I hope that I manage to convey that there is nothing intrinsic about TSIK that precludes, say, the ASF xmlsec project to be reimplemented with a completely different set of APIs -- I think Apache could use several available layers for different uses. Hans
