Re: [higgins-dev] Agenda for Higgins developer call March 26 at noon ET

["slyakhov" <slyakhov@xxxxxxxxxxxxxx>]

>  I also thought that it would be best to just make them Serializable Java Beans..

 

+1.

 

> Do you think we could remove these IContext references?

 

Yes, there is no sense to use IContext to instantiate credentials object. I suppose, Jim added IContext.buildAuthNAttributesMaterials() method in order to ensure that IContext suppots appropriate credentials type. But if IContext does not support some type of credentials it could throw UnsupportedCredentialsException in IContext .open() method instead.

Thanks,
Sergey Lyakhov

 

----- Original Message -----

From: Markus Sabadello

To: Alexander Yuhimenko

Cc: Higgins (Trust Framework) Project developer discussions

Sent: Thursday, March 26, 2009 3:53 PM

Subject: Re: [higgins-dev] Agenda for Higgins developer call March 26 at noon ET

Hi Alex,

I totally agree!!! I also thought that it would be best to just make them Serializable Java Beans.. But the problem is that currently some of the Authentication Material classes need a reference to an IContext. I never really understood that.

Do you think we could remove these IContext references? If yes, then everything would be much simpler and we could just do what you suggest..!

Markus

On Thu, Mar 26, 2009 at 1:19 PM, Alexander Yuhimenko <ayuhimenko@xxxxxxxxxxxxxxxx> wrote:

Hello Markus,

Just some thoughts about IdAS Authentication Materials http://wiki.eclipse.org/Authentication_Materials.
It's really useful to have identifiers of  Authentication Materials. But It seams  Authentication Material may be just Serializable Java Bean.
* If it's serializable bean, it'll be able to be cached with  distributed cache framework (ehcache,jbosscache,...) on server side between few server nodes.
* Instead of defining methods for serializing (to/from XML, String, etc.) it will be more clear and flexible to implement serializing by using  other "manage bean" class. For example, current org.eclipse.higgins.idas.common.AuthNNamePasswordMaterials provides is not clear API, it may be make sens to move business logic to "manage bean" or "utility" class and leave just get/set for username an password fields.

--
thanks,
Alexander Yuhimenko <AYuhimenko@xxxxxxxxxxxxxx>

On Wed, 25 Mar 2009 22:08:55 -0400
Paul Trevithick <ptrevithick@xxxxxxxxx> wrote:

> Logistics
> Time: noon Eastern
> Dial-in: 1-866-362-7064 / 89-2048#
>
> Agenda
> 1. [Brian] 1.1M6 [1] - completed
>
> * Google Contacts CP is included
> * Our build system now supports Java 1.4 and 5.0 [Valery?]
>
> 2. [Brian, Paul] 1.1M7 Planning
>
> * Raising the bar
> * Implement new downloads page structure [3b]
> > * PSF file
> > * Wiki page with manual build instructions
> > * Automated build (if possible)
> > * Manual regression test link
> > * All dependencies as separate projects
>
> 2. [Brian, Alexander, Andy] Selector Architecture Harmonization
>
> * See [2]
> * Synchronizing CardStore status-update
>
> 3. [Mary] EclipseCON update
>
> 4. [Markus]  IdAS Authentication
>
> * Markus is working on a proposal [4]
>
> 5. [Paul] Website improvements
>
> * Moved ver2 staging area [5] to production
> * New ³All Selectors² diagram [6]
> * 2.1 New solution names [3]
>
> 6. [Paul, JohnB] Relationship Brokering With R-Cards [7]
>
>
> [1] http://wiki.eclipse.org/Higgins_1.1M6
> [2] http://wiki.eclipse.org/Selector_Architecture_Harmonization
> [3] http://wiki.eclipse.org/Higgins_1.1_Plan#Website
> [3b] http://wiki.eclipse.org/Higgins_1.1_Plan#New_Downloads_Page
> [4] http://wiki.eclipse.org/Authentication_Materials
> [5] http://www.eclipse.org/higgins/ver2/index.php
> [6] http://wiki.eclipse.org/Selector_Overview#H1.1_All_Selectors
> [7] http://wiki.eclipse.org/Relationship_Brokering_With_R-Cards
>

---

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