Phil,
I think I captured a new proposal out of this at http://wiki.eclipse.org/IdAS_API_Extensibility#Traditional_OO_extensions along with the advantages and drawbacks I see with it. I'll get a little more input tomorrow toward what people prefer.
You had also mentioned that we need to consider how one goes about extending an existing context provider such that it can handle new extensions. I think this defines a new IdAS player. Today we have an IdAS consumer, IdAS CP writer, and IdAS CP Deployer. We could say there is also an IdAS CP extender. Depending on the nature of the extension and its relationship with the underlying CP implementation, this person may or may not need to have intimate knowledge of the CP being extended.
I *think* we can separate this issue from the one presented at http://wiki.eclipse.org/IdAS_API_Extensibility but at the least, it's good to think about while weighing the options there. Anyway, I put a section called "CP extender impact" on each proposal so we can at least keep track of ideas.
Jim
>>> Phil Hunt <phil.hunt@xxxxxxxxxx> 12/05/07 11:54 AM >>> Jim,
Just to capture our offline discussion, we talked about a couple of alternatives: -------------- On one hand, there are the java interfaces, which we try our best to keep very abstract, so that any consuming application's code can be provider agnostic.
Then there is the context provider-specific configuration which goes quite far in the other direction. When dealing with that, the consumer has to have pretty intimate knowledge of the provider. --------------
I think maybe the best way is to go with Java interfaces for any functionality that should be available (or at least possible) across *any* provider. This makes the new functionality clearly documented and well exposed. It also allows the client code to test if the functionality is implemented by checking the interface. Over time, should an interface become "typical", it might be reasonable to deprecate older method signatures over time.
If however an extension or feature is specific to one provider (or 2) but does *not* make sense for all providers, then context provider- specific configuration would be the way to go. The client developer need not be aware of the feature, but at least the deployer could configure the feature.
In the case of IGF, implementation is meant to be supported across all providers, but each provider will be implementing policy differently. This suggests the need for IGF to have an interface as the implementation issues *need* to be abstracted from the client.
Also, note that in the case of IGF, the client is intentionally aware of IGF and needs to know whether the provider is fully capable. One of the benefits of being aware of IGF is that the client code can actually be more abstracted from protocol and deployment issues. To the developer, CARML is simply the application's schema (plus rights metadata). But to the deployer, it tells how to configure the services infrastructure to best meet the needs of the app. The "layers" of Higgins can then figure out how to map CARML requirements to data available from various context providers or federated sources (e.g. STS). The layers can then route to appropriate providers and configure protocol policies (e.g. WS-SecurityPolicy).
I propose creating a generic interface for policy extensions which would allow for multiple policy implementations like IGF & EPAL. For example, hypothetically, IContextIGF and IContextEPAL could be subclasses of IContextPolicy which subclasses IContext. A provider supporting both interfaces, could tell the type of interface being used by either method signature or by the type of Policy object that was passed in.
Finally, I think we've also talked about callouts or callbacks. I have a feeling this won't work unless the requirement just involves manipulating the data as it transits the IdAS interface. In the case of IGF and JNDI, we're likely talking about converting policy and encapsulating it in an LDAPControl. In the case of OpenID, it would be mapping policy to http fields. Etc. It may be doable as a call- out, but it may actually change how the basic call to the protocol is made. I suspect, we'll have to take it on a case by case basis.
Phil Hunt Oracle
On 5-Dec-07, at 8:46 AM, Tom Doman wrote:
> Jim, > > Actually, I think you're right. You'll probably have to implement > your best guess and let those who require it, drive changes. Right > now, Phil has the best use case, correct? I'd say, start there and > go for it! > > Tom > >>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 12/04/07 8:26 PM >>> > If history is an indicator of how to get input on a topic like > this, I should implement this in an obviously wrong way and then > wait until someone tries to code to it. > > Anyone have any input? > > >>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 11/30/07 6:48 PM >>> > > I need to know how to best address https://bugs.eclipse.org/bugs/ > show_bug.cgi?id=196390 ( https://bugs.eclipse.org/bugs/show_bug.cgi? > id=196390 ) > > > I put out a wiki page at http://wiki.eclipse.org/ > IdAS_API_Extensibility. This describes some of the proposed ways > of making APIs extensible. > > > If you're a context provider writer, or a consumer of IdAS (or just > interested at all), could you please look at this wiki and give > feedback. Feel free to add more proposals, or pros or cons to the > page, or talk about them here. I tend to favor #4 ( http:// > wiki.eclipse.org/IdAS_API_Extensibility#extendedOperation_method ) > and #1 ( http://wiki.eclipse.org/ > IdAS_API_Extensibility#Add_just_one_more_argument ) right now. > > > > > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
|