> Great... thanks for referring me as "less technically-minded".
> **Cough** I
> just think I am more "practically-minded" than "less technically-minded",
> although I have no clue how sockets work. ;-)
Eeek! Sorry if that's what it sounded like I meant. I assure you, I
didn't mean it like that.
> No doubt that a pure PHP
> client is faster and has less overhead over a PHP-PERL wrapper. However,
> you won't see any real-world difference unless you are processing
> thousands
> of "separate" lookups and registrations a minute. We are talking about
> milliseconds here.
True.
> My wrapper doesn't even touch PERL unless it needs to
> send a request to the OpenSRS servers. During the registration
> process, it
> only does so for the "lookup" and "register" request.
> [...]
> As for maintaining my wrapper, I have no doubt maintaining a two file
> PHP-PERL wrapper is far more easier than maintaining the dozens
> of files and
> modules require by the OpenSRS client. What happens if OpenSRS suddenly
> decides to use the String::Unicode module? You would have to
> port it right?
They did ... and I do. Wanna help? :) Or does anyone at OpenSRS have some
spare time?
I guess I'm thinking that if you run into a problem, it won't be immediately
obvious whether the problem is with your wrapper class, or the OpenSRS
client.
Basically, I think we both have valid reasons and approaches to the
"problem" of using OpenSRS in a PHP environment. Best of luck!
- Colin
