Packaging the API specification separately is, IMHO, a must ... even if no OAuth group ever existed.
Since, as Pid corrctly pointed out, we have no way to constrain the OAuth WG to use Amber, nor forbid them to use or write a reference to an Apache licensed code, once the API is done and done well, we can draw the WG attention to our efforts and see what happens. I personally hope that our API will be so good to be considered by the WG and became something that will eventually also be used by other implementors, or become a de-facto standard, and will work to make it good enought to be it. Simone 2010/6/15 Pid <[email protected]> > On 15/06/2010 16:43, Tommaso Teofili wrote: > > Hi all, > > > > 2010/6/15 Pid <[email protected] <mailto:[email protected]>> > > > > On 15/06/2010 10:28, Simone Tripodi wrote: > > > Hi all guys, > > > > > >> > > >> 1. API in "net.oauth." (to be contributed back to the OAuth WG) > > > > > > My opinion is -1 for the "net.oauth" package since seems to me a > > > little out of scopes. Please don't take it personally, but AFAIK > we're > > > not allowed to use Apache Incubator as a forge where we could > create a > > > codebase to contribute to some else, maybe our Mentors could > explain > > > us better :( > > > > The project proposal included a clear statement that the API spec > would > > be available to others wanting to create an alternative > implementation. > > There were no objections to this in principal. > > > > > > Pid, I read in the proposal that we're going to deal with "allowing > > re-use by other developers", and I am fully committed to it, not to > > I'm not sure I understand? > > The proposal is clear about the API spec being developed as a separate > component/package*. We'd then develop an implementation (and some > extras) against that API spec. > > > > develop an (alternative) API to contribute back to OAuth WG, and > > basically I couldn't see any reason for doing that. > > Just my opinion. > > Tommaso > > We'd only propose the API specification back to the OAuth WG (not the > implementation). In order to promote re-use we'd basically have to > propose it back to OAuth, no? (That's not to say that they'd welcome it > with open arms, they might of course completely reject it...) > > Otherwise, we're just building "Yet Another Java OAuth Implementation". > > > p > > > * Probably "org.apache.amber", maybe "net.oauth" later. > > > >
