On Thu, Oct 2, 2008 at 2:50 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 2, 2008 at 2:41 PM, Cassie <[EMAIL PROTECTED]> wrote: > > Anybody else want to chime in? > > We can either: > > > > 1. add SecurityToken.getContainer > > 2. add SecurityToken.getParameter(String key) > > 3. leave it as is and go find a different solution for SecurityToken > > extensions > > My rough order of preference: > - find a different solution, though I've got no idea what one would look > like. > - SecurityToken.getContainer() > - getParameter(String key) > > I don't like getParameter(String key) because it forces us to treat > all security token extensions as Strings. What if it's a List? What > if it's something else entirely? Realistically, it's going to be a string or something that easily serializes as a string. The security token is only so big. > Hrm. I do have some idea of what a good solution would look like, but > so far everytime I mention it people give me dirty looks. I'll try it > out on shindig-dev just to see where things go: > > Assuming that all instances of SecurityToken are generated by > deployment specific code, Shindig deployers can implement a single > subclass of SecurityToken for all SecurityToken instances they > generate. Shindig SPI implementations can then cast down to that > SecurityToken subclass. This type of pattern is remarkably common in > old school C code: opaque void* pointers are tossed around anywhere > you have two APIs that can't have compile time dependencies but do > need to call each other at runtime. Yeah, but down casting is problematic. C libraries generally don't mix and match with each other -- the pointer is opaque to everything but the code that produced it. They use opaque pointers so that consumers of the library don't do dumb things with them. In this case, both the code using the object and the code that produced it need to work with it.
