Re: Package proposal

Hi Alan - >Looks a little bit like OO gone mad.. - almost all >the classes I looked >at had 1 or 2 methods. >It looks like it could all be done in 1 class (or >maybe 2 if you really >are pushing it), and a simple configuration array. > >Regards >Alan Greatly appreciate the feedback. I wanted to keep the API simple for developers using the code (which I believe I've achieved), yet break things down internally enough to where the flex points would easily allow me to add and/or change services, should DynDNS change existing or expose additional (perhaps more complex) functionality through their REST API. The idea is simply that any "request" must implement a very basic interface - getParameter(), setParameter() and build(). All current requests ("dyndns", "statdns" and "custom") simply define a set of parameters unique to each particular request, and extend from a "common" base class that implements this interface. Should DynDNS expose additional services (such as registering, deleting DNS entries, etc), adding this functionality to the package would be a snap - simply create an additional request child class which defines a set of unique parameters and implements the above interface, either by extending the existing "common" base class or implementing the methods itself. Since the DynDNS web services are REST-based, as long as the request's implemented build() method returns an HTTP_Request instance, you're good to go. If the design, as it stands currently, would be a show-stopper as far as voting is concerned, I'd be willing to rework the API. I hope you can see where I was coming from, though... :) Thanks again for the feeback, more is welcome! Regards, --Bryan