I'm not trying to say that we should accept a half-baked new API, just
that, despite our best efforts, we'll likely mess up something
(interface or implementation).
We want people to use and stick to the new API (better versioning should
help us release quick fixes when we find aforementioned problems) to
avoid a mapred/mapreduce-esque split -- also a large concern to me.
My last msg was more concerned with _trying_ to keep 100% compatibility
with the 1.x API and addressing incompatible issues as they might arise
in the development of the 2.0 API, instead of a declarative _must_.
Mike Drob wrote:
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.
