Hi Kanak, Thanks for looking through, its still work in progress. I am trying to move things into api and still retain the ability to compilation which is why its taking longer because each time I move things I have to realign existing dependencies. Sometimes I will move classes because I did not have the bandwidth to break the dependency so you will see some classes in api which should eventually go away. i will start marking them with annotations like @Implementation
See responses inline On Sat, Mar 15, 2014 at 8:37 PM, Kanak Biscuitwala <[email protected]> wrote: > > Thanks, Sandeep. I like the general project layout. I have a few comments: > > - What is StringTemplate? [Sandeep] It was something I had to carry over from core, we need to remove that dependency. I just did not have enough knowhow as to what it was used for and whether to move it all into the class using it. I don't want that util in api but did not have enough time to clean that one up, it will get cleaned up next iteration. > > - StateTransitionTableBuilder is an implementation detail as long as you use > StateModelDefinition.Builder [Sandeep] I will move it back to core. > > - Session ID is a general property of anything running in the system, and > isn't necessarily solely related to IPC. For instance, the correct current > state of a participant is based on a session id match. [Sandeep] Does it have a place in the api? If it does should it be in model.id? > > - We're still very close to the physical model with classes that derive from > HelixProperty. Ideally, we want a logical model that is an aggregation of > properties. For instance, a ResourceConfig is an aggregation of the > rebalancer config, provisioner config, user config, constraints. This is a > combination of three classes that currently derive from HelixProperty: > ResourceConfiguration, IdealState, and ClusterConstraints. Similarly, a > logical ClusterConfig would consist of ClusterConfiguration and > ClusterConstraints. Actually come to think of it, ResourceProperty and > ClusterProperty would be better names for HelixProperty subclasses. [Sandeep] By physical model I imagine you are thinking how they are rested and/or realized? or are you thinking something else? Also what is a property and what is config and what is configuration in your mind? Are they three separate vectors? Do we have the compositions documented somewhere if so send me the link and I will rework the configurations into composites once I am done moving them into api. I still am not sure though that we have all the API elements we need to start building composites. > > - Given the previous point, does it make sense to have a second package with > just the physical model stuff? The dependency tree would be something like > helix-core depends on helix-api depends on helix-physical-model. Using the > physical model in the implementation is the easiest way to implement the API. > Maybe there are other ways we could do this, but I'm curious to hear > everyone's thoughts. [Sandeep] IMO, API should not be concerned with the physical model i.e. resting state, its how to use the different pieces of helix. The users of API are consumers who do not need to know how the physical model is achieved. > > Kanak > > ---------------------------------------- >> Date: Sat, 15 Mar 2014 20:06:25 -0700 >> Subject: Helix API Rework: Update >> From: [email protected] >> To: [email protected] >> >> Hi, >> >> I just pushed some more changes to api. >> >> I have added reworked the classes in api to remove dependencies from >> core. Here are the packages >> >> org.apache.helix.api - base package >> org.apache.helix.api.model - all base model classes are here (needs a >> bit more cleanup) >> org.apache.helix.api.model.id - all ids for the base model classes >> org.apache.helix.api.model.ipc - the message classes which are used to >> communicate between controller and participant >> org.apache.helix.api.model.ipc.id - ids for the ipc classes >> org.apache.helix.api.model.statemachine - All state model related >> classes are here >> org.apache.helix.api.model.statemachine.id - all ids for the state model >> classes >> org.apache.helix.api.model.strategy - this is where I put Rebalancer >> config, other things that can go here are provisioners >> >> Everything builds and is checked in. Like before my idea is to put >> things in buckets I thought made sense and then fine tune as the >> experts (Kanak, Kishore and others who have worked on the core) >> review and we decide on where the classes should eventually rest. >> >> This cut is open for review/rework as necessary. So feedback is welcome. >> >> Thanks, >> >> Sandeep >
