[PEPr] Comment on Web Services::Plesk

From: 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

« previous php.pear.dev (#48878) next »