+1 to Ian's proposal @purplecabbage risingj.com
On Wed, Feb 5, 2014 at 1:33 PM, Andrew Grieve <agri...@chromium.org> wrote: > Joe - I appreciate your effort and your input, but I don't appreciate > hostility on this list from anyone, including you. > This is a public list, and I see nothing wrong with sebb's email in this > thread. > If you are at the point that you don't want to receive emails from sebb, > then I would ask that you choose to ignore them, or to create an email > filter on your end. > > +1 to Ian's proposal. > > > On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser <bows...@gmail.com> wrote: > > > Can you please leave this list sebb? You opinion is unwelcome! > > > > On Wed, Feb 5, 2014 at 6:05 AM, sebb <seb...@gmail.com> wrote: > > > On 5 February 2014 13:20, David Kemp <drk...@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 <jso...@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? > > >
