shall we open an issue for this guys? I like shaz's suggestion of moving to a js based impl (and deprecating)
On Tue, Jun 19, 2012 at 6:40 PM, Shazron <[email protected]> wrote: > Well considering we (may?) have consensus on a half-year time-based > deprecation policy (not that we have agreed on deprecating this uuid > property), I guess this will stay for now. > > My notice to the list is that the iOS uuid implementation as I > proposed will change according to iOS version (but we'll cross the iOS > 6 bridge when we get to it) > > We could also move this to a JS based implementation of uuid, since we > ship this function: > https://github.com/apache/incubator-cordova-js/blob/master/lib/common/utils.js#L62 > - we call that, and save to localStorage, and retrieve etc > > That will make it pretty consistent across app platforms, and for our > docs. We should move away from privacy-breaking hardware identifiers > because of potential platform policy reasons (read: Apple). My > suggestion - if devs want this, they can write a plugin (it can even > be cross-platform - basically our existing uuid core implementation > ripped out as a stand-alone plugin). > > On Tue, Jun 19, 2012 at 1:04 PM, Brian LeRoux <[email protected]> wrote: >> Ya for sure cookies tend to get used that way. Really they are a >> persistence mechanism and any value in them is...well, any value you >> want, like say, a guid! =) >> >> Still think this is an app developer concern and good candidate for >> removal within the scope of the vision. Many apps dont even need this >> capability. (At first) >> >> >> On Tue, Jun 19, 2012 at 3:50 PM, Jesse <[email protected]> wrote: >>> uuid is essentially to identify an application install on a particular >>> device. >>> It makes sense in an installed app context, though not in a web-app context. >>> The web-app comparison would probably be cookies, which do not work >>> consistently across devices. >>> >>> On Tue, Jun 19, 2012 at 12:36 PM, Brian LeRoux <[email protected]> wrote: >>> >>>> > ...the more things we simply offload to call 'app >>>> > developer concerns' the less anyone will need our framework. IMHO this >>>> > would be pursuing the 'cease to exist' mantra from the wrong direction. >>>> >>>> how so? should we be advocating adding a unique identifier to web >>>> browser apis? (don't think it'll get much traction!) >>>> >>> >>> >>> >>> -- >>> @purplecabbage >>> risingj.com
