Arne Goedeke wrote: >over time. My general feeling about performance in Pike is also that in >many cases these things do not make a huge difference. However, feel
True. Then again, I'm planning on having large Pike farms serving hundreds of Socket.IO clients/browsers. Then performance starts to matter. >I have a general comment about adding things to pike 8.0. If you change >existing code it means that those additions somehow need be properly >tested before a release can be made. I think it makes more sense to add >those changes to 8.1 first and backport them when they have been found >to be sufficiently stable to be included in a _stable_ release. It also >allows letting the APIs and conventions settle without shipping that to >users. I know that there are no official rules about this, but I think >it makes life alot easier. Well, I agree, obviously. The issue here is clouded a bit by the following factors: - I discovered that WebSocket support in Pike 8.0 is a bit flaky here and there, so in all likelihood, not many people are using it in its current 8.0 form. - In order to get it working, I ended up fixing parts of it first. - I'm trying to run a Socket.IO farm on a production system, so I'd like the platform to be Pike 8.0 instead of 8.1. - I didn't expect to fix this much. I'd had hoped that compression was already supported by the current implementation. - The EngineIO and SocketIO stuff is completely new, so no backwards compatibility issues. I expect the API to settle within a few days, because then I've built a running application with it. All that said, if a Pike 8.0 release needs to be done and the code is not deemed sanctioned/stable yet, I'll happily (temporarily) strip it back out again, and then reschedule putting it back in at some later point in time. -- Stephen.
