[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: More thoughts about Project Nori organization
First, Mike, thanks for hosting the first call today.
After the call, I had a few more thoughts about what's really going to work best for the growth of a healthy XDI open source ecosystem.
The first one is, as Joe I think was trying to explain, that the goal of Project Nori was for different implementations (who want to participate) to be able to do so under one umbrella, where they can share resources, agree on common interop tests, etc.
So, while I know at the conclusion of the call we said, "Yeah, let's go forward with it as Nori", we should clarify that meant, "under the Nori umbrella".
When it comes right down to naming, I think that means that each reference implementation project that "plugs in" to Project Nori should have a subdomain under projectnori.org. So:
danube.projectnori.org <== for Markus's project
{gluu-implementation}.projectnori.org <== for your project
{scala-implementation}.projectnori.org <== for Joseph's project
etc.
Secondly, I think all of them are "reference implementations", i.e., all of them are examples of XDI codebases, and no one codebase is THE reference implementation.
Thirdly, I'm thinking that pretty quickly, email traffic about implementation issues for Project Nori as a whole as well as for specific projects is going to ramp up and swamp other topics here on the XDI TC list, so we should:
1) Move Project Nori cross-project discussions (like this one) back to the Project Nori Google Group, and
2) Start lists/groups for each specific project that needs one.
Thoughts?
=Drummond (off to a lunch now - back online in a few hours)
On Mon, Jan 24, 2011 at 7:50 PM, Joe Johnston <joejohnston10@gmail.com> wrote:Hey Guys,
Sorry I've been silent on the list for a bit. I've been swamped
getting our startup up and running.
Mike, glad to hear you're plowing ahead with code.
The purpose of Project Nori (at least as several of us were originally
envisioning it) is to provide a central community site for
interoperable PDS implementations. This would make a lot more sense
if there actually were multiple interoperable implementations out
there. =)
However, the value of the Project Nori site is minimal without a test
suite or at least some code that can run against other
implementations. I'd love to see an official Project Nori client and
server, but it will require some logistics to officially find a legal
home which was the main reason to keep Markus's Project Danube
separate from Nori for the moment.
So, my recommendation is to develop code and figure out legal stuff
later. Code rules. Everything else is just wallpapering. Use
whatever code repo you like (I'd recommend github) and we'll link to
it from Project Nori. Any general documentation like specs and test
suite docs should be posted on the Project Nori web site. Project
specific documentation (like install instructions) should generally
just live with the code itself (like on the project's github wiki).
As for messaging, it'd be nice if your project says it's a Project
Nori implementation. I kinda think of it like a ruby Rack
application. At some point, Project Nori will be a framework that can
spin up implementations on a server and provide an endpoint that
routes requests to the configured implementations.
I'll try to join the PDS Retreat call this Friday to help out however I can.
Cheers,
Joe
--------------------------------------------------------------------------------
Joe Johnston
@simple10
--------------------------------------------------------------------------------
On Mon, Jan 24, 2011 at 2:00 PM, Markus Sabadello
<markus.sabadello@xdi.org> wrote:
> I also agree that Gluu should go ahead and start this new XDI project.
> Like Mike says, this should provide an important feedback loop for the XDI
> TC and the XDI community in general.
> I also agree it probably makes sense for this project to be part of Project
> Nori, although a more clear definition of Project Nori may be helpful,
> because nobody really knows what it is.
>
> Myself, I am also excited about eventually implementing the new graph model
> in XDI4j and Project Danube, but will wait until there are stable
> specifications.
>
> Looking forward to then doing interop with others :)
>
> Markus
>
> On Mon, Jan 24, 2011 at 6:20 AM, Drummond Reed <drummond.reed@xdi.org>
> wrote:
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]