Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.219.41 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAOBL_k6wuoD39gTv3qeBEom=LR6TJae9iekr1qs_6Xymr7mONQ@mail.gmail.com>
References: 
 <CABiQX1XB2_Tok9+DZ7ajFfK-A_YL3hf1N2t5kBQr+nWQByJ8Ag@mail.gmail.com>
 <CAOBL_k4XUU0-=uHOM2RimHUS=xYNULUwTLEpQLYihqH4Zkza2w@mail.gmail.com>
 <CABiQX1WB23Jg92VjWbLzcBJfRFy7CtEq9+O5EzYTkJb6rv-KPA@mail.gmail.com>
 <CAOBL_k4=xcBi88oEHzOz5A1_nDVBAGo78zC-nNBiW8zCQAX3cg@mail.gmail.com>
 <D6D4639B-D6BD-46E2-9E0D-A5FAF3C78D57@gmail.com>
 <CADVgkyNYqZ3=BMnhft4_-r-yEozvGyU5UKTsBQ2J16stcDszNQ@mail.gmail.com>
 <CABiQX1W6VmZhnj7OOM0e_5N2xYRNzN__1Neeobg1nJzy9GGX+w@mail.gmail.com>
 <CAOBL_k4Yxi5PnWTCiDNvOzK3J+7LfKBXjcGuTEgK3Ty9jkrgLg@mail.gmail.com>
 <CABiQX1VcNkg+P-3tN=1GUwGapEExGmE3DaSR56Yi52NYGhCpcQ@mail.gmail.com>
 <CAOBL_k6T=BivPKQ18Cu2ybqkZhQJmZbfF4++eEVNPnP+P7u1pw@mail.gmail.com>
 <CABiQX1W6qcfOmx3W8U9_puCmgKATTRS2WZic5Vx11ug-jm-Oeg@mail.gmail.com>
 <CABiQX1Vef_EPCjXQJjxZD8annJtZbBCxAXGwN8ixsinez7KG4A@mail.gmail.com>
 <CAOBL_k5KJyUfvr+_-Pfpfmz9B1E-fww72JU-CgFRipDeK44AMQ@mail.gmail.com>
 <CAOBL_k6wuoD39gTv3qeBEom=LR6TJae9iekr1qs_6Xymr7mONQ@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Tue, 9 Jul 2013 19:11:50 -0400
Message-ID: 
 <CABiQX1VFqTahwyRcDE1qBp4JKnW6eAtn2PrGoDxwa8gNoOuv0w@mail.gmail.com>
Subject: Re: Android - Removing the .api namespace
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=089e0129526a67b10804e11c4a0e

--089e0129526a67b10804e11c4a0e
Content-Type: text/plain; charset=ISO-8859-1

 :) okay, now let's see if I can convince you Joe.

What I've done so far was put classes in o.a.c.api that extend the actual
implementations in o.a.c. This is a bit more annoying than I'd like,
because for it work properly, most types must continue to refer to the
o.a.c.api classes, or else you'll get a type errors when dealing with
non-updated code that expects a o.a.c.api class.

Using a separate namespace (.api) to indicate which methods are a part of
our public API has the huge draw-back of not allowing us to make use of
package-private visibility with the classes in the non-.api namespace. This
is my main motivation for the change. I think Java devs often assume any
symbol that is public is a part of our API, and I think that's pretty
reasonable. Going forward, we should make an effort to convert public
symbols to package-private symbols. This will break any plugin that is
relying on the symbol, but will *not* break any plugins that are not using
the symbol. OTOH, a namespace change, as we're doing here, will break all
plugins.

So... I'd like to do the complete namespace change now so that when
we privatize symbols that we don't want to be a part of our public API, it
will not break the large majority of plugins.

If you're not convinced, please say why :)


On Tue, Jul 9, 2013 at 5:33 PM, Joe Bowser <bowserj@gmail.com> wrote:

> Actually, on second thought, no, let's keep the compatibility classes
> in for now.  We may want to keep using this namespace post-3.0.  I
> think I misunderstood what was being asked.
>
> On Tue, Jul 9, 2013 at 2:28 PM, Joe Bowser <bowserj@gmail.com> wrote:
> > On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> >> Want to bring this up again.
> >>
> >> There was a bit of discussion on the bug:
> >> https://issues.apache.org/jira/browse/CB-4038
> >>
> >> I've already gone ahead with creating backward-compatiblity classes in
> the
> >> .api namespace, but I think it would be better to just delete them.
> >>
> >> Main points in favour:
> >> 1. For 3.0, people will need to do some work to their plugins anyways
> (add
> >> plugin.xml + refactor their JS into modules comes to mind)
> >> 2. The change to plugins is trivial. Just replace all occurrences of
> >> "import org.apache.cordova.api" with "import org.apache.cordova".
> >>
> >
> > I'm OK with it for now, only because we don't have the time to
> > formalize the Android Plugin API.  I would have liked to keep the api
> > separation but perhaps we can revisit this 3.1 or 3.2.
>

--089e0129526a67b10804e11c4a0e--