Thanks, Sandeep. I like the general project layout. I have a few comments:
- What is StringTemplate? - StateTransitionTableBuilder is an implementation detail as long as you use StateModelDefinition.Builder - 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. - 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. - 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. 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
