> I did. Great work by the way.
Thanks.
> However, my approach is totally different
> from yours. You attempt to rewrite the all the PERL modules into
> PHP which
> I find to have major drawbacks because the PERL modules keep
> getting updated
> and you need to make constant changes. My approach is just to write a PHP
> wrapper to pass PHP commands to the PERL modules and have the PERL modules
> pass the values back to the PHP wrapper. My PHP wrapper should not break
> with new updates unless there are drastic changes to the PERL client
> protocol which I doubt would happen.
We used to do things that way ourselves. However, I wanted a pure PHP
solution for two reasons.
First, I prefer PHP. :)
Second, there is extra overhead in having PHP convert the data, call Perl,
retrieve the result and parse it. Keeping the entire process in PHP is
undoubtably faster (processing-time-wise), and probably easier for the less
technically-minded. Plus, you only need to maintain one set of code, not
your PHP wrapper *and* the OpenSRS client.
That said, yes it is sometimes a pain when OpenSRS releases new code.
However, I've attempted to "translate" the Perl code into PHP, rather than
"rewrite" it. That way, when a new client comes out, I can run a diff
between
the new and old Perl clients which basically tells me what changes I need to
make to which files in my PHP client. Pretty painless, usually.
Of course, PHP doesn't have much Unicode support, which is why I haven't got
around to multilingual domain support yet. Someone feel like porting
String::Unicode to PHP? :)
- Colin
BTW, there is a developers mailing list for my PHP client. Very low
traffic.
Join if you like at http://opensrs-php.sourceforge.net/
