incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: Plan for device specific APIs?
Date Mon, 19 Mar 2012 17:15:48 GMT
>No, the user would NEVER have to add the new modules/plugin, the build
>would "make it so".  Is that what you mean by API?  Or do you mean the iOS
>compass API is SUPPOSED to be different than the portable compass API?  I
>thought the idea with the 'device-specific' APIs is that a platform could
>provide an alternate implementation that had the exact same interface.  In
>the iOS compass case, providing an alternate, closer-to-the-metal, more
>performant implementation, that still matched the Cordova portable API for
>compass.

We are on the same page, here.   I guess I didn't explain it well enough.
 iOS DOES implement the 'portable' compass apis which request compass
headings over time. People developing a cross platform application would
want to use the portable apis.  However, iOS has additional apis that are
better suited to reading the compass changes on iOS based on a distance
filter rather than over time.  I want to add these device specific apis
into the compass object so someone who is developing only for iOS OR who is
willing to have divergence in their HTML/JS code could take advantage of
the more efficient api for iOS.  I just don't understand what our mechanism
is/will be for achieving this.  The same goes for Contacts - iOS has
ADDITIONAL features that are currently implemented off of the contact
object.

I don't want to add them using our current plugin implementation because
that creates a new JS api  -window.plugins.compass.watchHeadingFilter
rather than the current navigator.compass.watchHeadingFilter.   But, I'm
not sure if this type of extension is in our plans?

-becky

On Mon, Mar 19, 2012 at 12:37 PM, Patrick Mueller <pmuellr@gmail.com> wrote:

> On Mon, Mar 19, 2012 at 12:16, Becky Gibson <gibson.becky@gmail.com>
> wrote:
>
> > Ok, so I understand the desire for the JS to be "unified" for development
> > and testing purposes however,  we still do have device specific versions
> of
> > the main Cordova javascript  file. Thus,  I don't see why we can't add
> the
> > device specific API's that were already there, back into the "main" JS?
>  If
> > we do not, then we have broken the existing apis.  A person that was
> using
> > the iOS device specific contact apis, now has to add in a plugin and
> modify
> > their code to use a different namespace for these apis.
> >
>
> There's a couple of thoughts here.  I DO want to allow for
> 'platform-specific module implementations' for things like compass.  The
> only question is how to easily integrate this into the existing source
> directories, and the build.
>
> re: "we have broken the existing apis. A person that was using the iOS
> device specific contact apis, now has to add in a plugin and modify their
> code to use a different namespace for these apis."
>
> No, the user would NEVER have to add the new modules/plugin, the build
> would "make it so".  Is that what you mean by API?  Or do you mean the iOS
> compass API is SUPPOSED to be different than the portable compass API?  I
> thought the idea with the 'device-specific' APIs is that a platform could
> provide an alternate implementation that had the exact same interface.  In
> the iOS compass case, providing an alternate, closer-to-the-metal, more
> performant implementation, that still matched the Cordova portable API for
> compass.
>
> >I continue to dream of the day when all our
> > >existing "plugins" are structured as 3rd party plugins anyway.
> >
> > However, I don't believe we plan to get to this goal for 1.6. I also
> don't
> > believe we will have a mechanism for the user to modify a "standard" file
> > to select just the features they want in the main cordova js file or to
> > extend existing objects in the JS file for 1.6?   Thus, when this does
> get
> > implemented they will again have to modify their code to adjust the
> api's.
> >  I think it would be best to mitigate as much of this churn as possible.
> > IOW I'm advocating for adding the device specific api's into the 1.6 main
> > cordova js file with the idea that eventually they could be removed when
> we
> > provide a user option to selectively add them back in.
>
>
> I don't think that a user of a Cordova plugin, whether it's provided by us,
> or someone else, in the long term, should even have a choice of whether
> they get the 'device specific' or 'portable' implementation.  That's up to
> the plugin provider to decide.  If some user REALLY, REALLY wants to
> override the implementation of the provider of the plugin, now you're
> venturing into "fork" territory.  Which is absolutely fine, assuming you
> know what you're doing.
>
> --
> Patrick Mueller
> http://muellerware.org
>

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