helix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kanak Biscuitwala <kana...@hotmail.com>
Subject RE: Helix V2 0.7.0
Date Sat, 22 Feb 2014 18:45:50 GMT
+1 for helix-api as a package that only contains interfaces.

> Date: Sat, 22 Feb 2014 10:44:19 -0800
> Subject: Re: Helix V2 0.7.0
> From: g.kishore@gmail.com
> To: dev@helix.apache.org
> CC: user@helix.apache.org
> Good suggestion, I think Vinayak had suggestions on similar lines but I
> think he suggestion writing high level api's on top of existing api's, as
> opposed to changing the changing the underlying implementation. What that
> means is we leave the existing api's as is but add high level api. What
> this means is we can keep the core as is but add helix-api module that
> provides high level interfaces. We can re-use existing implementation under
> the hood. I like the idea of creating a separate module helix-api that is
> decoupled from implementation. This will enforce us to have no dependency
> on zookeeper in api and allows one to plug other forms of storage. For
> example many usecases dont need the level of consistency we get from
> Zookeeper.
> Looks like we might have to make decisions on a case by case basis.
> Can we make a decision of having a helix-api package.
> thanks,
> Kishore G
> On Sat, Feb 22, 2014 at 10:09 AM, Kanak Biscuitwala <kanak.b@hotmail.com>wrote:
>> The biggest problem is that we pretty much have to backport bug fixes
>> forever if we completely break compatibility. Here's what I think we could
>> do:
>> 1) Remove APIs that we're confident no one uses or can use (the alerting
>> stuff)
>> 2) Keep the interfaces for the most common currently used APIs
>> (HelixManagerFactory, HelixManager, HelixAdmin, ClusterSetup, command line,
>> REST), but use our new implementations underneath (HelixConnection,
>> HelixController, HelixParticipant, HelixSpectator, HelixAdministrator).
>> This means there will be breakages for people who used the implementation
>> classes directly, but the changes would be minor.
>> 3) Provide adapters between common new and old APIs
>> (HelixConnectionAdapter is an example)
>> 4) Maintain the model package as-is
>> This way, there's a clear transition path from one branch to another and
>> we can eventually end support for the old branch.
>> ________________________________
>>> Date: Sat, 22 Feb 2014 07:33:10 -0800
>>> Subject: Helix V2 0.7.0
>>> From: g.kishore@gmail.com
>>> To: dev@helix.apache.org; user@helix.apache.org
>>> Hi,
>>> We have made lot of good changes in 0.7.0 and improved the api's.
>>> However, I think it is not easy/intuitive for a new user. One of the
>>> problems with 0.7.0 code is that we tried to maintain complete backward
>>> compatibility with respect to both logical api's and physical layout on
>>> zookeeper.
>>> Trying to maintain the logical api backward compatibility has
>>> definitely caused some pain and did not allow us to do the right thing
>>> in 0.7.0 and it has made our code base huge. The reasoning here is -
>>> when we built Helix ((almost 3 years back), we did not anticipate Helix
>>> being used in other systems. So our main focus was minimal code and to
>>> make sure it works for the use case we had. We did not gather much
>>> feedback from users.
>>> However, we are seeing the usage grow and while everyone agrees that
>>> the high level concepts are good, it is apparent that api's are making
>>> people shy away from Helix. I would even say some of the terminologies
>>> are confusing until you spend quite some time with Helix.
>>> I want to see what others think about this.
>>> We have two options going forward
>>> Option1: Continue to maintain backward compatibility and improving the
>> api's
>>> Option2: Break the api compatibility and call it Helix V2. We redesign
>>> our api's and make it more intuitive and easier/flexible to use.
>>> I think the core functionality and design is great and don't see much
>>> change needed in the architecture (Do let us know if you think we need
>>> any change). What is lacking is documentation and a simple set of api's
>>> that are intuitive.
>>> While Option 1 is great for existing users, I prefer Option2. We will
>>> redesign the 0.7.0 api's without maintaining backward compatibility.
>>> Lot of work has already been done in 0.7.0, so we are not that far.
>>> This also gives chance to the community to contribute and provide
>>> suggestions/feedback/ideas.
>>> For existing users, we will continue to maintain 0.6.2 and continue to
>>> make critical bug fixes. But no new features will be added.
>>> Thoughts ?
>>> thanks,
>>> Kishore G
View raw message