cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Woghiren <m...@chromium.org>
Subject Re: The plugin repos and reality
Date Fri, 05 Apr 2013 19:00:02 GMT
We should slow this process down a little bit.  Our next step should be to
structure the plugins in the existing repos so that the process of
relocating them to their individual repos is straightforward.  Trying to do
it as we go will be messy and lead to the types of problems that prompted
Joe to make this thread to begin with.  Let's not "plugin-ize" anything
until we've done the meat of the work in the existing repos.

One major task that will help this process is to ensure that no plugins are
coupled.  We can remove visibility from all methods in native code (eg.
privatize methods on Android, remove signatures from headers on iOS).  In
this way, we can locate and deal with dependencies that will make the
eventual plugin migration difficult.

In Javascript, most of the work is already done.  We just need to create
plugin.xml for each of the plugins (once we've truly determined what they
should be).

So let's hold off on actually doing any inter-repository code movement; it
should be the final step, and should be done once it essentially already *
has* been done in the existing repos.  I don't know that I see the point of
rushing to have it done before 3.0.


On Fri, Apr 5, 2013 at 10:32 AM, Lucas Holmquist <lholmqui@redhat.com>wrote:

> Is there currently a list of plugins that can be moved,  i can start to
> move some,  but don't want to repeat what someone has done already
> On Apr 3, 2013, at 3:53 PM, Brian LeRoux <b@brian.io> wrote:
>
> > Agree w/ Anis. Just move what can be moved and file up tickets for
> > that which cannot be done in the immediate term / that is in the
> > 'official' list of plugins.
> >
> > On Wed, Apr 3, 2013 at 11:27 AM, Anis KADRI <anis.kadri@gmail.com>
> wrote:
> >> I think a good first pass is to plugin-ize what is plugin-izable and
> leave
> >> everything else (platform specific code) as part of the 'core'
> >> implementation. Things will never exactly be exactly the same across
> >> platforms in my opinion.
> >>
> >>
> >> On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser <bowserj@gmail.com> wrote:
> >>
> >>> Hey
> >>>
> >>> I've started moving the various Android plugins into their
> >>> corresponding repositories, and it seems that these were made up, and
> >>> that they don't really correspond to what exists in the code today.  I
> >>> don't think that it's realistic for us to get this done for 2.7
> >>> because there are certain plugins that don't have a home (i.e. App,
> >>> Compass, AudioPlayer, Echo) and others that don't make any sense to
> >>> have (i.e. Console, Vibration) or are unclear (Media).
> >>>
> >>> Also, at least for Android, we're going to have to nail down a Java
> >>> API.  Many of the plugins use some common code for file manipulation
> >>> such as the Capture, Camera and of course the File APIs. It would be
> >>> good to actually expose them to plugin developers so that we're all on
> >>> the same page as to where files should and should not go.
> >>>
> >>> It would have been good to create the repositories based on what we
> >>> already have implemented more or less, and to go from there.  That
> >>> being said, I don't know if there is a one-to-one mapping between
> >>> Android and iOS components, let alone any of the other platforms.
> >>>
> >>> Anyone else have thoughts on this?
> >>>
> >>> Joe
> >>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message