Return-Path: Delivered-To: apmail-incubator-amber-dev-archive@minotaur.apache.org Received: (qmail 3698 invoked from network); 15 Jun 2010 17:20:25 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 15 Jun 2010 17:20:25 -0000 Received: (qmail 70538 invoked by uid 500); 15 Jun 2010 17:20:25 -0000 Delivered-To: apmail-incubator-amber-dev-archive@incubator.apache.org Received: (qmail 70512 invoked by uid 500); 15 Jun 2010 17:20:25 -0000 Mailing-List: contact amber-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: amber-dev@incubator.apache.org Delivered-To: mailing list amber-dev@incubator.apache.org Received: (qmail 70503 invoked by uid 99); 15 Jun 2010 17:20:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jun 2010 17:20:24 +0000 X-ASF-Spam-Status: No, hits=-1255.2 required=10.0 tests=ALL_TRUSTED,AWL,HTML_MESSAGE,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 15 Jun 2010 17:20:24 +0000 Received: (qmail 3658 invoked by uid 99); 15 Jun 2010 17:20:03 -0000 Received: from localhost.apache.org (HELO mail-wy0-f175.google.com) (127.0.0.1) (smtp-auth username simoneg, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jun 2010 17:20:03 +0000 Received: by wyb39 with SMTP id 39so1271263wyb.6 for ; Tue, 15 Jun 2010 10:20:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.152.196 with SMTP id h4mr7738544wbw.61.1276622401370; Tue, 15 Jun 2010 10:20:01 -0700 (PDT) Received: by 10.216.2.199 with HTTP; Tue, 15 Jun 2010 10:20:01 -0700 (PDT) In-Reply-To: <4C17A91F.3060503@apache.org> References: <4C079515.3040701@pidster.com> <4C079FF9.8050907@pidster.com> <4C164369.5030001@pidster.com> <4C17559A.9000107@pidster.com> <4C17A91F.3060503@apache.org> Date: Tue, 15 Jun 2010 19:20:01 +0200 Message-ID: Subject: Re: Roadmap From: Simone Gianni To: amber-dev@incubator.apache.org, pidster@apache.org Content-Type: multipart/alternative; boundary=0016364d1c4bbefb53048914d08e --0016364d1c4bbefb53048914d08e Content-Type: text/plain; charset=ISO-8859-1 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 > On 15/06/2010 16:43, Tommaso Teofili wrote: > > Hi all, > > > > 2010/6/15 Pid > > > > > 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. > > > > --0016364d1c4bbefb53048914d08e--