cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: The plugin repos and reality
Date Thu, 04 Apr 2013 03:39:06 GMT
for netinfo, I think it's fine to not delay deviceready since we can just
set it to "unknown" at the start.

For device though, if we're not going to delay deviceready, then we should
remove the "device" symbol being exposed so that the only way to get to the
properties is through the async API. For this, probably step one would be
to deprecate the device symbol.


On Wed, Apr 3, 2013 at 11:31 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> I think we mostly had this names discussion already:
>
> http://callback.markmail.org/thread/cgvj6cnu7dna7umj#query:+page:1+mid:pz23mpifkcyewv2e+state:results
>
> In terms of moving files out, I think we should go slowly and just focus
> on 1 or 2 until we get it right. I'm a bit worried that bugfixes will need
> to be applied to both repos until we get to 3.0.
>
> Although, maybe another option is to package plugin files that have been
> moved into their own repos back into the core repos as a part of the
> release bundling process? That way we won't have two copies of things?
>
>
>
> On Wed, Apr 3, 2013 at 8:26 PM, Shazron <shazron@gmail.com> wrote:
>
>> Forgive me if this was already discussed, for the plugins:
>> 1. cordova-plugin-device
>> 2. cordova-plugin-network-information
>>
>> deviceready event being dispatched will not be dependent on these two
>> anymore right? At least on iOS it is currently.
>>
>>
>>
>> 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