We should not expose ZNRecord in the api. This should only the used in core and in fact it should only be used in the final step of persisting data to ZK or anything underlying store.
what do you think about having a separate package for configuration under model and all XXXConfiguration classes go in there. Message is overloaded. we should have a base class and have concrete class for each MessageType. Nice to have not must have. Overall looks good, we shud get started on the administrator class. Mainly support the CRUD operations. Thanks, Kishore G On Sun, Mar 16, 2014 at 10:44 PM, Kanak Biscuitwala <[email protected]>wrote: > > I see, makes sense. > > I should be clear, when I say "physical model" to refer to HelixProperty > subclasses, it's close to what you would probably call an SPI. It's still > independent of the backing store, but probably should either not be used > directly, or be present as an attribute of a more complete class. Basically > all I'm saying implementation of that more complete class would be greatly > simplified if we can use those HelixProperty subclasses internally. What is > the right way to shield the user from these classes while still using them > ourselves? > > Session ID is purely a runtime attribute of a participant and a > controller. It should be readable by the user, but never writable. > > Kanak > > > ---------------------------------------- > > Date: Sun, 16 Mar 2014 15:46:44 -0700 > > Subject: Re: Helix API Rework: Update > > From: [email protected] > > To: [email protected] > > > > 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 > >> > >
