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.