11–15 of 15 posts
I have a question regarding socket programming in general. Let's say I want to build some sort of notification service. This could be instant messages, presence indication, or notification of file changes ala dropbox. Now let's say that most of my clients are behind firewalls, forcing me to tie up one of my ports for each client as I do long polling or something else to keep the connection through their NAT open. How…
Why not use a class? http://pear.php.net/package/Net_Socket Or at least use namespaces. There is no reason to stick with the native PHP wrappers. It's common knowledge that PHP function names are illogical because of backward compatibility. So why not use a wrapper? I think it's sad that even after PHP got all these features so that it resembles a proper programming languages, people aren't even using them! Makes me…
You seem to be under the assumption that classes are always categorically better than a procedural API. I think you're mistaken. Classes aren't always a good abstraction. Classes being a good abstraction: $user = new User('John', 'Doe'); $user->authenticate($token); Classes being a bad abstraction: $two = Math::add(1, 1); // or worse: $math = new Math; $three = $math->sqrt(9); In that latter case, you'd be much bette…
OO is a good way to think about sockets because sockets are state machines. There's nothing wrong with passing around a socket called "this" to every procedure, but if you're doing that then you're just doing OO clumsily (i.e. without the benefit of being able to transparently substitute an SSL socket at a later point in time).
I think this is a good place to enter the "Right tool for the job" argument. The right tool not being PHP. Code here looks good on first look tho.
I've written plenty of sockets based PHP programs that run reliably and were easy and efficient to create. I didn't come across any problems that weren't easily surmountable.
If you're going to propose an negative argument, it would be helpful to at least outline the basis on which you are making it.
I think this is a good place to enter the "Right tool for the job" argument. The right tool not being PHP. Code here looks good on first look tho.
Which is entirely why I have a disclaimer up top: "Note: For many reasons PHP is not an optimal language choice for creating servers or daemons. I created this library so if you must use PHP for these things, you can do it with ease and produce great results. But if you have the choice, Java, Python, Ruby, etc, are all better suited for this."
But there are enough reasons to use PHP (and enough people doing it) that good libraries like this socket library (and the Daemon library I linked above) are a really valuable contribution to the PHP community.
I think this is a good place to enter the "Right tool for the job" argument. The right tool not being PHP. Code here looks good on first look tho.
Let me preface by linking to a project of mine that is very much in the "things PHP is not great at" category - https://github.com/shaneharter/PHP-Daemon Which is entirely why I have a disclaimer up top: "Note: For many reasons PHP is not an optimal language choice for creating servers or daemons. I created this library so if you must use PHP for these things, you can do it with ease and produce great results. But if…