I would very much like the new API to be something that we think has the right shape, ignoring implementation details. Otherwise we end up with something like a mapred/uce split and that still has people confused about which is the right one.
On Thu, Dec 4, 2014 at 8:46 AM, Josh Elser <josh.el...@gmail.com> wrote: > Can we reach a compromise here that the general idea that had been > presented will be followed and, of such an impasse is found in supporting > the old api, we will have another discussion on what to do when we actually > have a concrete problem? > > I feel like we can't get around this issue otherwise since it's a > hypothetical worry. > > Planning on both APIs to be around saves us from having to get the new api > 100% right the first time around (because we all know the current api still > isn't there :)). > On Dec 4, 2014 9:24 AM, "John Vines" <vi...@apache.org> wrote: > > > On Thu, Dec 4, 2014 at 8:15 AM, Sean Busbey <bus...@cloudera.com> wrote: > > > > > On Dec 4, 2014 6:55 AM, "Josh Elser" <josh.el...@gmail.com> wrote: > > > > > > > > (I was still confused so I just chatted with John on the subject of > his > > > -1) > > > > > > > > He was under the impression that it would not be feasible to leave > the > > > existing 1.X APIs in place with the creation of the 2.0 APIs; whereas, > I > > > had assumed that this wouldn't be an issue. > > > > > > > > He brought up the issue of how we plan to handle exceptions in the > new > > > API which, would very likely, include changes to the Thrift APIs as > well. > > > If this is the case, we'd now have to support the 1.X API (while it > > existed > > > as deprecated) as well as the new 2.0 API. This would likely affect how > > we > > > actually want 2.0 API to operate. > > > > > > > > This all kind of boils down to confusion over whether or not there is > > any > > > compatibility between 1.x and 2.0. If 2.0 is a clean break from 1.x, > this > > > thread is pointless. Otherwise, we risk not getting the APIs we really > > > want. > > > > > > > > Does this help clarify the concern? > > > > > > > > > > One way to address that kind of concern would be to only support the > 1.x > > > APIs via an optional different end point. > > > > > > We obviously don't have enough information at this point to evaluate > how > > > much such a separation would take to implement nor how maintainable it > > > would be. > > > > > > But there at least seems to be a way to work through that issue if it > > comes > > > up. > > > > > > > I hope so. But until we have a new API fully implemented that we're > content > > with, I don't think we should have any guarantees made about > compatibility > > of the 1.x API, just in case we end up hitting an insurmountable issue. > > >
