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:48:36 GMT
Sorry, I meant module.

----------------------------------------
> From: kanak.b@hotmail.com
> To: dev@helix.apache.org
> CC: user@helix.apache.org
> Subject: RE: Helix V2 0.7.0
> Date: Sat, 22 Feb 2014 10:45:50 -0800
>
> +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
>>> 		 	   		  
Mime
View raw message