Since I assume vdsClient will use libvdsm. It should have all the constants
I do like Adam's suggestion about making vdsClient auto-generated as well.
vdsClient is currently very annoying to maintain.
I would also like to propose changing the name of the executable to vdsm_cli.
It would make it easier to distribute both tools as vdsClient will still be
needed communicate with old VDSMs.
Also capital letters in executable names is not very Unixy.
----- Original Message -----
> From: "Adam Litke" <a...@us.ibm.com>
> To: "Vinzenz Feenstra" <vfeen...@redhat.com>
> Cc: firstname.lastname@example.org
> Sent: Wednesday, December 12, 2012 10:40:19 AM
> Subject: Re: [vdsm] Request for consideration during the API revamp
> On Wed, Dec 12, 2012 at 02:01:31PM +0100, Vinzenz Feenstra wrote:
> > Hi,
> > When there is the attempt to enhance/change the current API, I
> > would
> > ask you to consider to think also about the vdsClient use case.
> > I haven't read anything regarding that so far and therefore I just
> > want you to think about it as well.
> > My expectation is that the vdsClient will continue to use the RPC
> > interfaces, however since it is part of the VDSM project I think it
> > would be a good idea if there is a way for both vdsmd and vdsClient
> > to share constants used for the API.
> > That in turn also should simplify the maintenance of vdsClient.
> > Currently I see the constants used by both being defined on both
> > sides and I am pretty sure that this could be improved.
> > See this as just a thought on the whole redesign talk, but I would
> > like to see this kind of use cases to be covered. :-)
> Yes, this is an excellent suggestion. One thing I am thinking about
> doing is
> generating a new python file with the enums defined in the schema.
> This could
> be included by all server-side code and by clients such as vdsClient.
> If we
> decide to add constants to the schema file, we could also place these
> into the
> same generated python file.
> Adam Litke <a...@us.ibm.com>
> IBM Linux Technology Center
> vdsm-devel mailing list
vdsm-devel mailing list