One more thing: the specific implementation changes to cordova-js (for platform overrides and cleaning up the platform definition files) is being tracked in that issue Pat linked to: https://issues.apache.org/jira/browse/CB-280
On 3/19/12 10:43 AM, "Filip Maj" <[email protected]> wrote: >+1 from me in everything turning into a plugin down the road. >+1 for refactoring the filter method into a "quirk" property of the >Compass Options that is iOS-specific > >And yes, currently the overriding/merging implementation in the JS is not >optimized. As Pat says, we are wasting bytes every time we do a >platform-specific merge or override. That being said, putting a bit more >love into the build process and platform definition files can solve that >problem. > >On 3/19/12 10:39 AM, "Jesse MacFadyen" <[email protected]> wrote: > >>I think the 2 iOS calls for compass can coexist peacefully if it is >>refactored to use the filter value as an option in the original call >>to watchHeading. Other platforms could ignore this option, or even >>implement it and this could be considered a quirk. Exposing another >>method on compass, (and presumably possibly geolocation, and >>accelerometer) for this makes no sense to me. >> >>For contact picker functionality IMHO this should be a plugin, but >>that does not mean it cannot augment the existing navigator.contact >>object. >> >>Cheers, >> Jesse >> >>Sent from my iPhone5 >> >>On 2012-03-19, at 10:16 AM, Becky Gibson <[email protected]> wrote: >> >>>> 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 <[email protected]> >>>wrote: >>> >>>> On Mon, Mar 19, 2012 at 12:16, Becky Gibson <[email protected]> >>>> 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 >>>> >
