>>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
I think we should put the re-usable static methods in cloud-utils only if they will be of use to multiple other components. If the utility methods serve only cloud-api then they should still stay with cloud-api. -Prachi -----Original Message----- From: Rohit Yadav [mailto:[email protected]] Sent: Wednesday, January 09, 2013 4:54 PM To: [email protected] Subject: Re: [DISCUSS] Breaking out interfaces to cloud-utils or create a new artifact cloud-contract 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.
