Hey guys, I checked in a strawman for the helix administrator and helix client api classes. There are command classes, id classes and model classes which tie up the two client apis. The idea is mutation is only allowed by Administrator API, the client API is only used for discovery.
Please take a look and let me know of the structure and composition. I decided to not go with the composition model as we had discussed i.e. HelixCluster having APIs for the creation of entities under it as separation between administrator client and regular clients was getting clumsy to achieve. So, I decided to switch back to a HelixAdministrator and HelixClient based approach which worked better. Here are the highlights * The api.role package is no longer needed and all its constituents are represented in the model package. * The existing contents of the api.client package now seem to be candidates for spi project (something I plan to start on in parallel soon). In other words HelixConnection, HelixConnectionBuilder, HelixConnectionFactory, HelixConnectionFactoryListener seem to be internal concerns to the implementations of the API. * If the structure looks good, I will next start on fleshing out the contents of each of the command classes. I presume there should be existing code I can get information from so I will start there when I get a chance. I will need help on the commands, so will ping at the appropriate time. * The contents of api.model package like ZNRecord, ZNRecordDelta etc will move under the implementation in core. I will keep HelixConfiguration and have configurations derive from it and these will eventually get translated before storing into the specific implementation. As usual this is work in progress but wanted to give early visibility so feedback, comments are welcome. Thanks, Sandeep
