Comments for "Services_RackCloud"

» Submit Your Comment
Please log in to enter your comment. If you are not a registered PEAR developer, you can comment by sending an email to
» Comments
  • Brett Bieber  [2010-05-18 19:36 UTC]

    Woohoo. I think this package could be useful. Some initial thoughts -

    I'd change the private methods to protected, unless you're really certain.

    As is, the curl extension should be added to the package.xml as a required dependency, but I'd recommend using HTTP_Request2 for the communication layer. Not everyone will have the curl extension enabled or available.

    Second is the Exception. I know PEAR (1) tells you to extend PEAR_Exception, but I'd be in favor of using the new PEAR2 exception standards which don't require the additional dependency. As it is, you're extending PEAR_Exception, which is in the PEAR package, but that is not listed as a required dependency.

    The example.php could go into a docs or examples dir, and bundled with the package.

    That's all the tips I have for now. I'm very interested in what others think.
  • Pedro Padron  [2010-05-19 14:27 UTC]

    Nice proposal! I can already see myself using this.

    While reading your example.php I was wondering if you could abstract the whole "format" thing. I don't really care which format will be used to process my request, I just need the data in a convenient format such as an array or object, but for me it is important that this output data format is consistent regardless of the request format.

    If someone who cares about the request format decides to change it from json to xml, it would be great if only $rackcloud->setFormat('xml'); could do the trick, instead of having to also change from json_decode() to simplexml (or other xml parsing lib) somewhere else in their code.

    This is just a suggestion, I don't think this should be considered a blocker for package approval.
  • Till Klampaeckel  [2010-05-20 18:43 UTC]

    I know I'm being super picky, but maybe add this code to a github repository so we can browse the code online? :-)

    Also, the name, I'd be in favour of Services_RackSpace_CloudServers because this would allow us to group API wrappers for CloudFiles etc. in there too. :-)

    This would also follow Services_Amazon_*.
  • Ken Guest  [2010-05-24 13:43 UTC]

    Your current iteration of the code looks quite good, but why have a redundant
    parent::__construct($username, $secret);
    in the constructor for Services_RackCloud_Servers ?