GSOC 2011: ssc - Week 2
In terms of user functionality, searching for software, templates, appliances and packages has been implemented this week. The actual api calls are performed by handler classes like SSC::Handler::Appliance which exposes public methods like list, show, repositories and installed_software. I’m trying to follow a template that allows any command of the type ssc <class> <action> <arguments> to map directly to Class#action(arguments) with minimum modification along the way. The command line arguments (—option value) are parsed into an options hash that keeps getting passed down the stack and used as necessary. Right now I’m not happy about exposing data that is unnecessary for certain functions via this hash but it makes sense to have the checking of data in the handler action rather than at the top level which makes that inevitable.
There’s been some abstraction and refactoring to make way for having the .sscrc file what will hold the appliance configuration in the appliance directory. Right now there isn’t a lot of validation of options and the parser merely merges options from .sscrc and the command line to pass into the various handlers.
One tiny useful takeaway from this week has been learning about the Method class. Its very useful in meta-programming. For instance when calling methods with the Class#send method it would be useful to make sure that you’re passing the correct number of arguments. The Method#arity method can be used to check the number of arguments that a method takes before passing arguments to it.
Next week I’m going to be focusing on the structure of the appliance directory and handling those commands that work locally.
