Thanks for the feedback. I've put my thoughts inline. On Thu, Mar 24, 2011 at 1:53 PM, Cornelius Schumacher <cschum@suse.de> wrote:
On Thursday 24 March 2011 06:52:12 Ratan Sebastian wrote:
Here's some of the commands the client would have. I had a look at osc and the Studio API in coming up with this. Let me know what you think.
That's a good start. One general problem we have to solve is how to make it clear, which commands work in which context. The list you made includes commands which work locally, like the files commands, and commands which work remotely like the templates or appliances commands, and to make things more complicated there are commands which need both, like the diffs.
The way I thought it might work is that only commands involving GET requests perform the action immediately(searches, listing, diffs) . Anything involving a PUT, POST or DELETE (adding or deleting repositories, packages) will be stored locally and the actions aren't performed until the `ssc commit` command is run. (This could be made flexible with some sort of --perform-now flag appendable to all those commandswhich runs the commit for that particular change). So basically any action that requires information from the API will require you to be connected whereas any changes that you make can be done locally. I think that's a intuitive scheme.
Additionally it makes a difference, if you call the client within an appliance or outside of an appliance. All this could be very confusing. I think we need a consistent scheme how to deal with that, so it's clear which commands apply to what, if you see and change things locally or remotely, and which appliance is the context.
One option could be to separate command line tools, and have one for working inside an appliance and another one for working independent of a local appliance. But this could also be reflected in the structure of the commands. Ideas and good concepts are welcome.
Maybe we could move all the commands that require you to be in the appliance directory into an appliance namespace (i.e. ssc appliance respository add) and generic commands can be used outside like(ssc repository search). Another option is to keep the commands as is. In this case it would load the values of the different parameters as required from the manifest file or from the options and errors out if any parameter is unspecified.
-- Cornelius Schumacher <cschum@suse.de>
-- Ratan Sebastian -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org