Paul Scott wrote: > I am developing a webservice like module for our framework that will > enable downloads of module code into the framework modules from a remote > server. > > Basically what this should do is: > > 1. User requests a list of available stable modules from server > 2. User clicks on install from the returned list > 3. Client code will download a tgz/zip module and plonk it in the users > modules directory (taken care of) > 4. Framework then unzips/untars it and installs (taken care of) > > My question here is... > > For the server/client code, I am thinking around REST (much the same way > as the PEAR channel server works). Is this the wisest choice? Should I > rather go with FTP or a mail request or something? If I go for FTP, that > will require the PHP FTP extension, how common is that in shared hosting > environments? > > The file size of a typical module is around 100k, and we must take into > account that this is in/for bandwidth starved Africa. Is REST/SOAP > robust enough to do that? > > Any help would be greatly appreciated! Hi Paul, Why not use PEAR itself? The last chapter of my book (http://www.packtpub.com/book/PEAR-installer) is a step-by-step tutorial on designing just such a module that would allow downloads of module code from a remote server. It also includes all the code, which is publicly and freely available from the pear.chiaraquartet.net channel (package MyBlog). The code is a useful example of embedding the PEAR installer and of designing customized REST, but it might be tricky to understand the design methodology without the prose of the book. The question of how to do what you describe is something I have thought about a LOT because of the requirements of the PEAR Installer. One of the specific design choices in PEAR 1.4.0 and newer was to make it easy to embed PEAR to act as a plugin module. The chapter in question also examines other successful attempts to design remote plugin repositories including Serendipity's Spartacus and Seagull's use of the PEAR Installer to show other ways of implementing a plugin manager. One thing I found very interesting was that even though Spartacus is extremely lightweight, it was easy to design a much more sophisticated plugin manager using PEAR with the same number of lines of code. You need not use PEAR's actual installation process unless you find it convenient (I do - file transactions are a must-have if you want to be able to recover from botched downloads and so on). In any case, do check out the solution in the book, I'm sure it will solve the problem you describe quite elegantly. Good luck, Greg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
