Re: Can a PEAR package rely on an external PHP script

2008/6/16 Martin Jansen <martin@divbyzero.net>: > On Sun, Jun 15, 2008 at 11:07 PM, Jonathan Street > <jonathan@torrentialwebdev.com> wrote: >> I'm considering putting together a PEAR package for interacting with a >> web service. Conceivably there are two packages needed, one to handle >> authentication and a second to fetch the data. There is already a >> script available to handle the authentication but nothing available >> for fetching the data. Is it appropriate to rely on the existing >> script for authentication or should they both be PEAR scripts? The >> usage would be along the lines of: >> >> $auth = new externalClass; >> >> $credentials = $auth->processLogin($authVars); >> >> $data = new PEARClass; >> >> $results = $data->fetch($credentials); >> >> It would be possible to port the external class to a PEAR package but >> the specification is frustrating to work with and I would prefer to >> avoid this if possible. > > If you have already implemented the spec in PHP, what is the real > problem with porting it to PEAR? Usually this only involves adjusting > method names, comments, indentation and such. The external class wasn't created by me and I suspect there would be some resistance in changing the license to something more PEAR friendly. My understanding is that porting the functionality to PEAR would require a complete rewrite to avoid any copyright issues. > >> I can't see anything in the documentation which would prohibit this >> but I'm also unaware of any other packages doing similar. > > I don't think there is a rule against this, but I doubt it makes > sense. If people can't use your PEAR package without fetching more > code from external resources, what is the advantage of having the > package in PEAR at all? > > Martin >