From phil.hunt at oracle.com  Wed Dec  5 10:54:16 2007
From: phil.hunt at oracle.com (Phil Hunt)
Date: Wed, 05 Dec 2007 10:54:16 -0800
Subject: [Igf-dev] [higgins-dev] IdAS API extensibility
In-Reply-To: <47567358.4A7B.00E4.0@novell.com>
References: <47505AE5.D091.001C.0@novell.com> <4755B812.D091.001C.0@novell.com>
	<47567358.4A7B.00E4.0@novell.com>
Message-ID: <8E27D860-97BF-4DB2-91CB-E2A05362A4B9@oracle.com>

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 at novell.com> 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 at novell.com> 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 at eclipse.org
> https://dev.eclipse.org/mailman/listinfo/higgins-dev



From phil.hunt at oracle.com  Thu Dec 13 14:00:25 2007
From: phil.hunt at oracle.com (Phil Hunt)
Date: Thu, 13 Dec 2007 14:00:25 -0800
Subject: [Igf-dev] Possible bug in schema
Message-ID: <1FBD9CD5-EF54-49B6-A2C8-4A9260149BE0@oracle.com>

I notice a problem that has come up with regards to "operations".   
Operations (add, modify, delete, etc) are currently defined against  
schema and not against Interactions.

I am wondering if operations should be defined solely against  
Interactions?

We could continue to also state whether an attribute is read/ 
writable...but I think that should be solely defined within an  
interaction.

Phil Hunt
Oracle


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/igf-dev_lists.openliberty.org/attachments/20071213/e380fbbe/attachment.html 

From phil.hunt at oracle.com  Thu Dec 13 16:26:47 2007
From: phil.hunt at oracle.com (Phil Hunt)
Date: Thu, 13 Dec 2007 16:26:47 -0800
Subject: [Igf-dev] Possible bug in schema
In-Reply-To: <1FBD9CD5-EF54-49B6-A2C8-4A9260149BE0@oracle.com>
References: <1FBD9CD5-EF54-49B6-A2C8-4A9260149BE0@oracle.com>
Message-ID: <5A5EB30D-46C5-4E29-AC0E-3C6BF8CA7B62@oracle.com>

Sorry if this is repeated. It didn't seem to work the first time.

Phil Hunt
Oracle


On 13-Dec-07, at 2:00 PM, Phil Hunt wrote:

> I notice a problem that has come up with regards to "operations".   
> Operations (add, modify, delete, etc) are currently defined against  
> schema and not against Interactions.
>
> I am wondering if operations should be defined solely against  
> Interactions?
>
> We could continue to also state whether an attribute is read/ 
> writable...but I think that should be solely defined within an  
> interaction.
>
> Phil Hunt
> Oracle
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/igf-dev_lists.openliberty.org/attachments/20071213/2da2a921/attachment.html 

From brett at projectliberty.org  Fri Dec 14 10:54:07 2007
From: brett at projectliberty.org (Brett McDowell)
Date: Fri, 14 Dec 2007 13:54:07 -0500
Subject: [Igf-dev] Possible bug in schema
In-Reply-To: <1FBD9CD5-EF54-49B6-A2C8-4A9260149BE0@oracle.com>
References: <1FBD9CD5-EF54-49B6-A2C8-4A9260149BE0@oracle.com>
Message-ID: <A549A3BA-6737-4F14-AAE7-067A8EEA7474@projectliberty.org>

Is this only an implementation issue or also a specification issue?

On Dec 13, 2007, at 5:00 PM, Phil Hunt wrote:

> I notice a problem that has come up with regards to "operations".   
> Operations (add, modify, delete, etc) are currently defined against  
> schema and not against Interactions.
>
> I am wondering if operations should be defined solely against  
> Interactions?
>
> We could continue to also state whether an attribute is read/ 
> writable...but I think that should be solely defined within an  
> interaction.
>
> Phil Hunt
> Oracle
>
>
> _______________________________________________
> Igf-dev mailing list
> Igf-dev at lists.openliberty.org
> http://lists.openliberty.org/mailman/listinfo/igf-dev_lists.openliberty.org



From jimse at novell.com  Wed Dec 19 18:09:41 2007
From: jimse at novell.com (Jim Sermersheim)
Date: Wed, 19 Dec 2007 19:09:41 -0700
Subject: [Igf-dev] [higgins-dev] IdAS API extensibility
In-Reply-To: <8E27D860-97BF-4DB2-91CB-E2A05362A4B9@oracle.com>
References: <47505AE5.D091.001C.0@novell.com>
	<4755B812.D091.001C.0@novell.com><47567358.4A7B.00E4.0@novell.com>
	<8E27D860-97BF-4DB2-91CB-E2A05362A4B9@oracle.com>
Message-ID: <47696C75.D091.001C.0@novell.com>

Phil, 

I think I captured a new proposal out of this at http://wiki.eclipse.org/IdAS_API_Extensibility#Traditional_OO_extensions ( 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 at oracle.com> 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 at novell.com> 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 at novell.com> 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? ( 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 at eclipse.org
> https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev at eclipse.org
https://dev.eclipse.org/mailman/listinfo/higgins-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/igf-dev_lists.openliberty.org/attachments/20071219/214f9228/attachment.html 

From prateek.mishra at oracle.com  Thu Dec 27 07:26:40 2007
From: prateek.mishra at oracle.com (Prateek Mishra)
Date: Thu, 27 Dec 2007 10:26:40 -0500
Subject: [Igf-dev] No call today
In-Reply-To: <5A5EB30D-46C5-4E29-AC0E-3C6BF8CA7B62@oracle.com>
References: <1FBD9CD5-EF54-49B6-A2C8-4A9260149BE0@oracle.com>
	<5A5EB30D-46C5-4E29-AC0E-3C6BF8CA7B62@oracle.com>
Message-ID: <4773C430.9020609@oracle.com>

The igf call is cancelled today - we will be back on schedule next week.