Agreed! I didn't see that either until now.
On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams <tommy@devgeeks.org> wrote:
> Of course, while writing my rant, Ian has summarized a great proposal.
>
> +1 to the below!
> On 06/02/2014 2:51 am, "Ian Clelland" <iclelland@chromium.org> wrote:
>
>> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny <mmocny@chromium.org> wrote:
>>
>> > Honestly, my opinion on this: Leave the default as-is for now. We've
>> just
>> > made huge changes to the API, which may have bugs / implications we
>> haven't
>> > fully thought through.
>>
>>
>> That's a really good point. If we do this right now, we have two huge
>> changes going on at the same time, and we will have to deal with a lot of
>> heat for bugs *as well* as the location change.
>>
>>
>> > Lets let a subset of users upgrade to the new
>> > $MAJOR version, and a subset of those add the new preference. In a later
>> > release, we can make the switch -- by then, maybe we will have more
>> > solutions for migrating.
>> >
>> > Also, this is a nice to have, but its obviously been a situation that
>> devs
>> > have been living with for years.
>> >
>>
>> That is something that I was thinking about last night. If we go with #3;
>> put in a safe default, then we could spend a year if we wanted to promoting
>> hard the "please please please switch to the better version" position.
>>
>> Then we could announce long in advance that we're changing the default, or
>> that we're removing the default, and when we're ready, bump the major again
>> to 2.x and do it.
>>
>> This might be the best situation for the developers, and it's no worse for
>> the users than the situation right now. It's less than optimal for the
>> "cordova ecosystem", but the ecosystem may be harmed more by angry
>> developers leaving the platform than by continuing to place files where
>> they are now.
>>
>>
>> So this proposal would be:
>> - Don't revert the changes made on dev
>> - Don't rename the plugin
>> - Add a default which places files exactly where they are now
>> - Bump the major version
>> - Start fixing bugs in the new code. (without being distracted by the
>> storage location change)
>> - Start blogging about the issue with storage locations, and encourage
>> people to change (but don't force them to do anything yet)
>> - In a year, or when we feel that a sufficient mass of developers have
>> gotten the message, broadcast that we're removing the default. (or changing
>> it, if we're very confident in our plugin upgrade paths)
>> - Some months after that, make the change. (and hopefully not be
>> distracted by bugs in the underlying plugin code) Bump the major version
>> again.
>>
>> I'm actually pretty happy with that; we think that the current situation
>> isn't great, but it doesn't seem to be actively hurting the ecosystem. And
>> any developers who think otherwise will now have the tools to fix it for
>> their own apps.
>> Eventually we can be more opinionated about it, and the plugin will be more
>> robust, so devs shouldn't be *as* angry as if we switched it right now.
>>
>> Ian
>>
>>
>> > -Michal
>> >
>> >
>> > On Wed, Feb 5, 2014 at 10:13 AM, sebb <sebbaz@gmail.com> wrote:
>> >
>> > > On 5 February 2014 14:55, David Kemp <drkemp@google.com> wrote:
>> > > > My concern with any automated fix is that we have no idea what files
>> > > belong
>> > > > to an app.
>> > > > The default is to just toss everything in the root.
>> > > > Files may be user data that is shared between apps, config files or
>> > temp
>> > > > files. The developer probably knows what to migrate - we don't.\
>> > >
>> > > The app must tell the library what file names are involved.
>> > > So unless the same API is used for files that are supposed to remain
>> > > in the root, it should be possible to know what needs to move.
>> > >
>> > > It may still prove too difficult to implement the merge, but perhaps
>> > > there is some scope for adding something to help the developers.
>> > >
>> > > For example, the code could check if there is a file with the same
>> > > name in the old location, and log a message if so.
>> > > There may be other checks that would help mitigate the breakage.
>> > >
>> > > >
>> > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb <sebbaz@gmail.com> wrote:
>> > > >
>> > > >> On 5 February 2014 13:20, David Kemp <drkemp@google.com>
wrote:
>> > > >> > -1 to merging reads. That just sounds like a horrible thing
to
>> > debug.
>> > > >>
>> > > >> Seems to me that developers using the plugin will have to implement
>> > > >> something similar in order to make it easier for their users.
>> > > >>
>> > > >> Would it not be better to spend the time getting it right once,
for
>> > > >> the benfit of all developers, rather than hoping they each get
it
>> > > >> right?
>> > > >>
>> > > >> I don't know what is involved here, so this is theoretical.
>> > > >> But I believe that compatibility should only be broken if necessary.
>> > > >> Also that fixing a problem at source is usually a lot cheaper
than
>> > > >> requiring downstream developers/users to do so.
>> > > >> There are lots more of them, so any extra effort they have to
expend
>> > > >> is multiplied many times.
>> > > >> In other words, the cost-benefit should not just look at the
>> immediate
>> > > >> cost to the project.
>> > > >>
>> > > >> > +1 to 'go big or go home'. Break it now. Break it obviously.
>> > > >>
>> > > >> But I agree that breakage - if decided on - should be obvious.
>> > > >>
>> > > >> >
>> > > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref <
>> jsoref@blackberry.com>
>> > > >> wrote:
>> > > >> >
>> > > >> >> Is it impossible to have reads merged from both locations,
but
>> > > writes go
>> > > >> >> to the new location, and when a write completes in the
new
>> > location,
>> > > >> delete
>> > > >> >> the old one?
>> > > >>
>> > >
>> >
>>