cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prachi Damle <Prachi.Da...@citrix.com>
Subject RE: [DISCUSS] Breaking out interfaces to cloud-utils or create a new artifact cloud-contract
Date Thu, 10 Jan 2013 01:03:54 GMT
>>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:rohit.yadav@citrix.com] 
Sent: Wednesday, January 09, 2013 4:54 PM
To: cloudstack-dev@incubator.apache.org
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 <Alex.Huang@citrix.com> 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:rohit.yadav@citrix.com]
>> Sent: Wednesday, January 09, 2013 3:53 PM
>> To: cloudstack-dev@incubator.apache.org
>> 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.


Mime
View raw message