Thanks, Joey. Great answer. I'm not sure that I agree completely but it does make me think that you may be the light at the end of the tunnel. Before I say much more, I'll try to do some testing of the sourceforge code. I thought that was completely obsolete. I'll also give CCS yet another try because I had little time and the major problems that I was seeing could have been ZendOptimizer based and that is my complaint about Zend Guard, in addition to the fact that the name sucks, "Guard", just the opposite of what you are saying;)
Since PHP5.1 I've had issues with ZendOptimizer. If that is ever completely ironed out, most of my complaints will loose their validity. I just want it to work in porduction. The opensource comments are more from a religious viewpoint. I know that tucows isn't responsible but they chose the tool, so. . . Thanks again for taking time to answer, have a great weekend. ed Quoting Joey deVilla <[EMAIL PROTECTED]>: > I'm going to answer a couple of questions raised in the last couple of > posts to this dicussion: > > 1. CCS: Why is so much of it encoded with Zend Guard? > ----------------------------------------------------- > (Note: Zend Guard is the new name for the product formerly known as Zend > Encoder.) > > The idea behind using Zend Guard wasn't to prevent anyone from looking > at the underlying code; in fact, we *do* make the full unencoded source > code available at these locations: > > - The "Client Code" section the Reseller Resource Center > (http://rrc.tucows.com/current). > - The "CCS" section of Tucows Developer > (http://developer.tucows.com/code/ccs) > > One reason we used Zend Guard was to clearly differentiate between "safe > to modify" code and code that should be modified only at your own risk. > The "safe to modify" sections of CCS were those bits of code that you > could customize for branding, to fit your workflow or to provide a > better user experience. The encoded stuff was the underlying plumbing, > and by locking it up with Zend Guard, we hoped to prevent less > experienced people from accidentally bunging up their client. > > The other reason we used Zend Guard was for performance. In encoding PHP > files, Zend Guard turns PHP files into code that runs faster when run in > a PHP interpreter with Zend Optimizer installed, and even faster when > run in a PHP interpreter with Zend Platform installed. I have been > informed that the "open", non-encoded version of CCS is considerably > slower than the version locked with Zend Guard. > > > 2. How can I integrate OpenSRS with existing PHP projects or > the PHP project I'm working on? > ------------------------------------------------------------ > I have two answers: a short-term one and a medium-term one. > > The short-term answer: Use the PHP OpenSRS Client, which is free (free > as in speech and free as in beer) from SourceForge at: > > http://sourceforge.net/projects/opensrs-php/ > > It's a bit short of documentation, but it *does* work! I'm going to talk > to Colin Viebrock, the original author, and see if I can become an admin > for that project and perhaps take it over (he's left the domains > business to pursue other interests). > > If you want an example of PHP code that utilizes this library, check out > my little app called "Duke of URL" (http://dukeofurl.biz), which uses > PHP OpenSRS Client to make use of the "NAME_SUGGEST" OpenSRS API call. > The code is available for download from the site. > > I will also start a series of articles on using the PHP OpenSRS CLient > library on the Tucows Blog (http://blog.tucows.com) -- keep an eye on it > over the next couple of weeks! > > And now, the long-term answer: over the next couple of months, I will > write a PHP library that wraps OpenSRS calls as PHP functions. The idea > is that if you want to see if "example.com" is available, you should be > able to call a PHP function like so: > > $result = lookupDomain("example.com"); > > and the variable $result should contain the response from OpenSRS. > > The plan is for the library to have a PHP wrapper function for every > OpenSRS API call, starting with the XCP ones (the ones for domains). > Hopefully, this library will be a piece of the "middle ground" solution > that will allow you to more easily integrate OpenSRS with your PHP projects. > > > As usual, questions, comments and suggestions are always welcome! > > -- > Joey deVilla - Tucows, Inc. - [EMAIL PROTECTED] > Technical Evangelist > "Nerdy Deeds Done Dirt Cheap" > http://blog.tucows.com + http://developer.tucows.com > _______________________________________________ > domains-gen mailing list > [email protected] > http://discuss.tucows.com/mailman/listinfo/domains-gen > _______________________________________________ domains-gen mailing list [email protected] http://discuss.tucows.com/mailman/listinfo/domains-gen
