incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Granqvist, Hans" <hgranqv...@verisign.com>
Subject RE: [PROPOSAL] Apache TSIK
Date Mon, 23 May 2005 02:52:49 GMT
>> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message