+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: [email protected] > To: [email protected] > CC: [email protected] > > 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 > <[email protected]>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: [email protected] >>> To: [email protected]; [email protected] >>> >>> 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 >>
