You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Ian Clelland <ic...@chromium.org> on 2014/02/05 05:00:07 UTC

CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

On Tue, Feb 4, 2014 at 6:20 PM, Joe Bowser <bo...@gmail.com> wrote:

> Don't do it!  I think File still needs some work:
>
> https://issues.apache.org/jira/browse/CB-5974


It's too early yet to tell whether this has become a problem, but obviously
this is something that people are going to run into (and are already
running into [1])

Background:

Because of CB-5915 [2] (and it's android sister, CB-5916 [3]), developers
who upgrade File will find that their applications crash with a log message
the first time they use any of the File API. (I'd crash sooner, but File is
not currently a load-on-startup sort of plugin)

There was a lot of discussion about this on the list [4], and I thought
that we had reached consensus, but maybe it needs one more hard look.

The Problem:

The log message hopefully tells them what they need to do to fix the
problem, but many (most?) devs aren't going to see it; they're only going
to see that their app is broken now, and come to us (hopefully) or
StackOverflow (more likely) to figure out why and what to do about it. They
will probably be loud, we will probably be blamed for their apps breaking
(no matter how simple the fix is,) and it will probably be a bad time for
everybody.

It's unfortunate that we feel we have to do this; there just doesn't seem
to be any other way to encourage developers to use anything but the old
locations for persistent files. On Android this is the
root-of-the-sdcard-even-if-its-just-a-partition-shared-by-all-apps
location. On iOS, its the Documents directory, although Library makes far
more sense for these sort of files.

If we added a default value, the only possible default we could use is
"Compatibility", which means that approximately 100% of new apps will ship
with that default. We *can't* use the new location as the default, because
that will cause real pain for the users, not the devs. Real users will lose
access to real data, and that worries me much more than a mob of angry devs
with pitchforks.


Options:

1. Go big or go home: Make it crash harder. I was already going to add a
paragraph to the plugin.xml file to be shown on install, but we *could*
make the app break on launch, rather than on the first use of File.
We could force File to load on startup, or we could make Javascript alert()
the dev on startup (something like "please fix config.xml and then delete
this line"), or we could break the plugin encapsulation and make
ConfigParser check for this special case.
Maybe we could go even further and find a way to make it break on build. At
least then apps wouldn't make it to the store broken.

2. Leave it the way it is. Brace for the angry mob with blog posts, release
notes, install guides, READMEs, vigilance on StackOverfow, and hope that
it's enough.

3. Put in the safe default and live with it. Accept that every single
Cordova app is going to use the default and that their file storage roots
will suck. By the time you've educated a developer, chances are their apps
have already been released and have users with stored data. Work hard on a
migration utility/plugin and make sure that it can never possibly lose data.

With my Google hat[5] on, I don't mind #3 -- we've ensured that the apps
created with our framework use the new defaults, since they're all new apps
by definition. Wearing my Apache hat, though, I don't think it's best for
Cordova in the long term. At some point, I think we should rip off the
bandaid. If we don't do it now, with a major rev bump of File, then we're
just postponing the hurt.

There may be other options; lets try to get consensus on this before
pulling the trigger.


[1] https://issues.apache.org/jira/browse/CB-5899
[2] https://issues.apache.org/jira/browse/CB-5915
[3] https://issues.apache.org/jira/browse/CB-5916
[4] http://markmail.org/message/tzcljj3xgycbkx3g
[5] http://www.flickr.com/photos/nooks/6858535568/

>
>
> On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong <ki...@hotmail.com>
> wrote:
> >
> >
> > Sounds good to me!
> >> From: agrieve@chromium.org
> >> Date: Tue, 4 Feb 2014 14:35:01 -0500
> >> Subject: Re: Plugins Release!
> >> To: dev@cordova.apache.org
> >>
> >> Sounds good!
> >>
> >>
> >> On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill <st...@gmail.com>
> wrote:
> >>
> >> > I am going to take the silence as lazy consensus. I will make sure to
> >> > include the new file plugin as well.
> >> >
> >> > I will make sure to have a blog post of changes to review before I
> publish.
> >> >
> >> > -Steve
> >> >
> >> >
> >> >
> >> > On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill <st...@gmail.com>
> >> > wrote:
> >> >
> >> > > Hey All,
> >> > >
> >> > > What is the general feeling on me moving forward with a plugins
> release
> >> > > today? I could start the process this afternoon if there aren't any
> >> > > objections or concerns.
> >> > >
> >> > > Are there any plugins that shouldn't be released?
> >> > >
> >> >
> >
>