Till Klampaeckel [2008-01-07 04:31 UTC] 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. :)
Joshua Eichorn [2008-01-07 16:12 UTC] I'm not sure there is a huge point to wrapping the Plesk API without doing any of the hard work of wrapping the actual API.
Also have you thought about using SimpleXML or at least having it be an optional return type from the methods.
In the plesk wrapper i wrote about 9 months ago I used a wrapped SimpleXML for all the return types.
I would also say that figuring out the API is the hard part, not communicating with the server.
(Note my wrapper didn't do a whole lot more then this, though I did wrap some of the basic setup features.
Pedro Padron [2008-01-07 16:52 UTC] Hello Till, thanks for the comments, you do have some interesting points.
Plesk API is available since version 7.5 (Windows and Linux/UNIX), and just last month version 8.3 was released.
My explanation about not implementing the API wasn't clear at all, and I am sorry about that. Let me try to clarify what I had in mind when I created this package.
Plesk API is quite complex. And when I say "complex" it can also mean "confuse". It doesn't follow any standard like XMLRPC or SOAP, for example. Among all protocol versions released so far, there has been some minor changes in the XML request/response structure.
If you take a look at the latest API documentation (for Plesk 8.3), you'll see that there has been 7 API protocol versions. This means that Plesk 8.3 supports all versions, but if you make your request specifying an old protocol, some functions won't be available. However, if you have a Plesk 7.5, you have to use that old protocol.
So, if I implement the whole API, it must be compatible with all Plesk versions, then we would have 7 different API implementations.
That's why my initial purpose when developing this package was to provide the basics for other developers to create their own API according to their needs, by providing an interface using PHP Arrays or raw XML as string.
The API entry point should definetely be configurable, I'll surely handle this in the next few days and submit the changes. The 8443 is the default for Plesk, but it can be configured to run on another port.
I don't think you are paranoid, an error treatment should be done in the _createResource() method, throwing a Services_Plesk_Exception exception(I also agree that this class must be created).
I will put ArrayToXml in a class and make it public, and also put a method to do the reverse process, like you suggested. Any idea of a class name?
While writing this I just received Joshua's comment, and I see that the central point of discussion is if the full API should be implemented or not. I am willing to do this package the most useful as possible, but I'm not quite sure about what would be the best approach to handle different protocol versions.
P.S.: Joshua, I have tried SimpleXML, but I had some problems with the Array <=> XML conversion in different API protocols.
Please let me know what you think about this.
Thanks a lot!
Joshua Eichorn [2008-01-07 17:00 UTC] API Version wise I would target the 8.x series, and just provide a method for people to make custom calls as needed
Pedro Padron [2008-01-07 20:22 UTC] Well, I guess it's an unevitable choice.
I will focus the development on protocol version 1.5.2.0 (Plesk 8.3).
As Joshua suggested, there will be a method for custom requests.
Considering that this will be the implementation of the API, we have several entities that can be handled, like: Mail Accounts, Domains, Services, Control Panel Sessions, FTP Accounts, Web Users, File Uploads, and several others.
My intention is to create a separate class for each entity, for example:
Services_Plesk_Domain
Services_Plesk_Subdomain
Services_Plesk_FTP_Account
Services_Plesk_Web_User
And then to make queries we could have something like a findAll() method (or any other name) and also some filtering options.
Till:
With this approach I believe it wouldn't be nice to perform different queries in a single request, since everything is separated in different classes. In your example we could have something like:
$arrayDomains = Services_Plesk_Domain::findById(array(1, 2, 3));
foreach ($arrayDomains as $domain) {
echo $domain->getName();
}
Joshua Eichorn [2008-01-07 20:55 UTC] A separate class per entity sounds good, i would make a base class for the entities to extend from
Till Klampaeckel [2008-01-08 04:13 UTC] > Services_Plesk_Domain
> Services_Plesk_Subdomain
> Services_Plesk_FTP_Account
> Services_Plesk_Web_User
I'd also suggest that you create a hub class (Services_Plesk) which is implemented by those childs. Anyway, sounds great.
> With this approach I believe it wouldn't be nice to perform different
> queries in a single request, since everything is separated in different
> classes. In your example we could have something like:
I can live with that of course. :)
Martin Jansen [2008-01-13 13:27 UTC] I agree with the other comments that you should try to support a bit more of the Plesk API. If there are several versions of it, supporting the current stable one should be fine. If the API is confusing, try to come up with an intuitive wrapper around it that makes it easy to use. That's what wrappers are good for. :-)
Also the code is not yet following the PEAR Coding Standards completely.
Pedro Padron [2008-01-13 15:42 UTC] Hey folks,
Thanks for the comments, I am now working on a new version of it, based on the latest API.
As soon as I have something decent to present I'll put the links here!
Bye!
Pedro Padron
Christian Weiske [2009-06-25 08:04 UTC] Is this proposal dead, or are you going to finish it?
Pedro Padron [2009-07-03 05:20 UTC] I'll get back to this proposal as soon as I finish my current work, which is somehow related to Services_Plesk: http://github.com/ppadron/parallels-ka-api/
By the way, I was thinking about renaming Services_Plesk to Services_Parallels_Plesk, because my other package is Services_Parallels_KA. KA stands for Key Administrator, it is an interface to manage licenses for Parallels products. What do you think? I thought about this after I saw Services_Atlassian_Crowd, which also follows the scheme category_vendor_product.
Anyway, probably in the next 2-3 weeks I'll have something new about this package, if you think it's not soon enough, I can propose it again when it's done.
Thanks!
Pedro Padron
|
