Re: More thoughts about Project Nori organization

[Michael Schwartz <mike@gluu.org>]

Drummond,

1) Personally, I think a project nori implementation and project nori code 
are not mutually exclusive. However, in the interest of time, I would like 
proceed with the project name as "OpenXDI," unless there are any 
objections (other then the precence of a squatter on OpenXDI.org).

2) I don't think it is a "Gluu" implemenation. My goal is to help 
kickstart an open source project.

3) We can either keep the XDI implementation call or convert it to an 
OpenXDI call. It doesn't bother me. Until the scala and danube project are 
active, I don't think we'll be swamped. But again, I'm flexible either 
way.

thx,

- Mike

--------------------------------------------------------------------------------------

Michael Schwartz
Gluu
Founder, CEO
mike@gluu.org
https://www.gluu.org
+1 646-810-8761



On Fri, 28 Jan 2011, Drummond Reed wrote:

> 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
>>>>
>>>
>>>
>>>
>>>
>>
>