OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] Lauch Nori: new XDI implementation


On Sun, Jan 23, 2011 at 1:47 PM, Michael Schwartz <mike@gluu.org> wrote:
>
> Attendees: Mike Schwartz, Markus Sabadello
>
> XDI Implementation Call #1 was cancelled, but Markus pinged me on IM, and we
> decided to have a quick meeting. Following are my notes.
>
> Markus was clear that he is not going to implement any code until the new
> XDI specification is much further along.
>
> I'm optimistic that Markus will continue to make valuable contributions on
> many fronts, however I do not think it is in the best interest of the XDI TC
> to wait much longer to start to code. The TC will otherwise miss an
> important feedback loop.

I agree that having implementation feedback on our candidate 1.0 specs
as we draft them will be very helpful. Multiple implementations
testing interop is even better.

> Delaying the development of XDI core code will also be detrimental from a
> marketing standpoint. Logistically, if XDI is words with no code, developers
> cannot go deep.

Agreed.

> Consequently, I would like to propose the following:
>
> 1) The XDI TC, or Gluu, to launch a SourceForge project for a new XDI
>   reference implemenation in Java. The goal would be to write code that
>   could be used for the development of XDI servers and clients.

While members of the XDI TC can participate, it's not within the XDI
TC charter (or the OASIS charter) for it to produce open source code
directly. And for good reason -- the job of the TC is to produce one
spec and let there be any number of implementations (open source or
closed source).

So it would be better for Gluu to lead it.

> 2) The code license would be GPLv3
>
> 3) The reference implementation would include the following components:
>   - Core XDI Model
>   - EJB style persistence mechanism
>   - asynchronous XDI server
>   - sample XDI command line interface (CLI)
>   - Python client API
>   - LDAP persistence mechanism
>   - OpenStack API scripts
>
> 4) Gluu would contribute programming resources to the project and would
>   provide project management for the code (Jira and Hudson).
>
> 5) The name for this project is TBD. Maybe we can use "Nori" since so much
>   discussion went into that name.

That's not really an XDI TC call because that's a separate open source
project (in which a number of XDI TC members are involved). My
understanding is that Project Nori is supposed to be a PDS interop
project, so it doesn't sound to me like the right fit for a PDS
client/server implementation. Rather this Gluu-led open source project
would be one of the member projects in Project Nori.

But Joe Johnston and others involved with Project Nori may have more
insight on that topic.

In any case, I'm all for having multiple implementions of our 1.0
specs as we start pushing them out.

Best,

=Drummond


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]