[PEPr] Comment on Web Services::Plesk
| From: | Till Klampaeckel | Date: | Mon, 07 Jan 2008 04:31:14 +0000 |
| Subject: | [PEPr] Comment on Web Services::Plesk | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-48878@lists.php.net to get a copy of this message | ||
Till Klampaeckel (http://pear.php.net/user/till) has commented on the proposal for Web
Services::Plesk.
Comment:
First off, a really great idea implementing the API. Plesk is all over the
place and I can see how useful this can be for many webhosts, especially if
you have more than one server and would like to handle them remotely, so to
speak.
(Btw, how recent is this a more feature of Plesk? I've never noticed it
before.)
I am somewhat not sure about your explanation of why you did not implement
the full API. I mean, even if I wouldn't want to use getAllDomains()
because I trade in flexibility I still see this as an important method
almost anyone would want to use in if they are using Plesk. The name of the
package is Services_Plesk and the fact that you are not implementing all of
the API is misleading for me, so maybe you can elaborate on this.
I'm also not so sure about the general request format - what I mean is,
even though it is pretty easy to read it still requires you to exactly
"learn" the entire API, which is of course not a bad thing but it's also
not very elegant.
What I mean is, instead of:
$arrayRequest["domain"]["get"]["filter" ]["id"] = 1;
I'd propose:
$plesk->getDomain(1);
You could call it multiple times - e.g.
$plesk->getDomain(1);
$plesk->getDomain(2);
This would "internally" build $arrayRequest and then:
$domains = $plesk->exec();
To request the data.
Just a suggestion though - not sure what others come up with, or what you
think about that yourself.
In regard to code, I've browsed through your code and I think the port of
the "Plesk appliance" should be configurable - or at least a class
variable. Same for the endpoint. I must admit though that I have no idea if
either of them are configurable (I would "guess" at least the port is) or
maybe subject to future changes - which is why I would avoid hardcoding
them.
Then maybe I am paranoid, but whatever happens if your curl request fails
- wouldn't your method just die in the middle. There is no error checking
whatsoever.
Speaking of which I think you should create Services_Plesk_Exception by
extending PEAR_Exception so people can "trap" errors which are specific to
Plesk in their app.
In general the code should adhere more to PEAR CS (documentation, etc.)
and I think ArrayToXML should probably be a class.
Btw, I generally like the idea of providing either "response formats" a
lot. And it would be also nice to offer a general way to convert XML to
Array and the other way around just in case someone needs to use something
like that when they build on top of your code.
Looking forward to your thoughts. :)
Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=523
--
Sent by PEPr, the automatic proposal system at http://pear.php.net