On 09-Jan-2013, at 4:28 PM, Alex Huang <[email protected]> wrote:
> That's actually what cloud-api is supposed to be. The problem is not there. > The problem is none of the plugin code should have build dependencies on > cloud-core and cloud-server. The Manager interfaces were not intended for > outside consumption. That will achieve better separation. You're right and I'm too not talking about breaking any interface that is for internal consumption of a component, but breaking out the interfaces that may be common for all components. The problem is cloud-api has the interfaces and also the cmd, response classes. and right now cloud-api depends on cloud-utils, so I cannot write re-usable static methods which can make use of interfaces defined in cloud-api (cyclic dependency), that's why I'm proposing this. Further, to separate out api-server as a standalone server and get rid of service layer, we'll need to do it. So one way is we split cloud-server as cloud-server and cloud-api-server, and we move all the cmd and response etc. classes from cloud-api to cloud-api-server, or create a cloud-contracts. > We can talk about breaking cloud-api into cloud-rest-api, cloud-plugin-api, > cloud-resource-api to reduce confusion as to what constitutes cloudstack api. > This can be confusing? Regards. > > --Alex > >> -----Original Message----- >> From: Rohit Yadav [mailto:[email protected]] >> Sent: Wednesday, January 09, 2013 3:53 PM >> To: [email protected] >> Subject: [DISCUSS] Breaking out interfaces to cloud-utils or create a new >> artifact cloud-contract >> >> Hi all, >> >> One of the challenges of writing good structural code in CloudStack is that >> the >> artifacts and their classes depend on each other with no code/filesystem >> structure. I want to discuss if it's a good idea to split all the interface >> classes >> files (from cloud-api, cloud-server, cloud-core) to either cloud-utils (which >> already provides a lot of reusable utils) or move them to a cloud-contract or >> cloud-interface artifact whose only purpose would be to provide interfaces >> or contracts between CloudStack components. The rules would be that >> cloud-utils provides reusable methods/utils via static methods and cloud- >> contract would just provide interfaces both of whose classes can be >> dependent on other classes within their artifact but they should be >> independent of anything else. >> >> This would be just a move refactor, can be done after javelin is merged, can >> be done after 4.1, but would make it easier to write components so they >> won't have have cyclic dependency, tight coupling and a better filesystem >> structure. >> >> Regards.
