Hi all, The main raison d'etre of TSIK was always simplicity. As it is now, TSIK runtime has only one single dependency, and that is on the ubiquitous log4j.
The freedom of a single jar, of a single download/compile to get XML/SOAP security related stuff going, without worrying about this and that other jar is very refreshing. It makes it difficult for the developer to screw up inadvertently. Again, simplicity is key, both for developers and deployers. To the greatest extent possible, I'd hate to lose that "instant usability" of TSIK. Also, since TSIK is still in incubation, I don't know whether it is prudent to depend on it too much. Could this not be a show- stopper? So, in theory the idea of pooling resources sounds good but I'm not convinced yet, for the above stated reasons. I have to think a bit. That said, I have only started in earnest looking at wss4j yesterday. I will know more what I think about everything in a while. :) Dims, do you have a simple sketch/outline how you see the various wss4j/tsik packages broken out and working together? That would definitely help me grok your plan. Thanks, Hans > -----Original Message----- > From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 24, 2005 7:58 AM > To: [EMAIL PROTECTED] > Cc: [email protected]; [email protected] > Subject: Re: WSS4J and TSIK > > +1 .. I'd like to see TSIK broken up a bit more (and maybe appropriate > parts moved to commons even?). > > Sanjiva. > > On Tue, 2005-08-23 at 11:16 -0400, Davanum Srinivas wrote: > > Hans, > > > > [CC'ing wss4j-dev mailing list] > > > > Can we make/keep TSIK a soap engine agnostic toolkit (remove the > > soap/transport stuff)? Then we can then position WSS4J as a project > > for implementing ws-security in specific soap engines like JAX-RPC, > > Axis 1.X and Axis 2.X. > > > > I'd also highly recommend abstracting out portions of WSS4J > behind an > > interface/factory such that we can plugin in TSIK based > implementation > > (and keep the existing implementation for some time since > folks depend > > on existing behavior). This way we can have implement OASIS > > WS-Security 1.1 just in TSIK and automatically get WSS4J upgraded > > instead of writing it twice. Same goes for say Kerberos > token profile > > or other profiles that we think are important. > > > > What do you think? > > > > thanks, > > dims > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
