The online racing simulator
WebSocket Support [RFC 6455]
I'd like to add WebSocket support as a module too PRISM.

The idea being that PRISM would be a WebSocket server and it's connections would be handled by the plugins as if they where packets from InSim. You'd do this by registering an endpoint, you can then give that end point to any plugin that wants to take part in that communication or sub-protocol. From there, parsing the packet down, it can be given too the plugin already part procssed by a module or raw as the prism_packets module would get an InSim packet.

These are some rough ideas, and I want to know what you guys would think would make this a robust but easy solution to use. I'd also love to take a peek at Victor's implementation for LFSWorld so I have some idea what I'm talking about.
I did this with xi4n a while ago, and I'd highly recommend pre-parsing the binary packets into json, protobufs or bson, rather than just passing them off as their raw bytes to websocket clients. My first iteration made the mistake of not doing this and it just made the frontend work painful.

It'll make consuming them much much easier in the long run. Personally I'm more of the opinion that json->insim is the easiest option for most things to consume.

Edit: I've just re-read your opening post and maybe I've misunderstood.
/me rubs eyes sleepily
I was thinking some thing along those lines, but I really don't have any idea where to start. To quote Steve Jobs, "Everything out there right now is shit." at least in PHP land. The require some odd choice to get Ratchet PHP to work and I really don't want that.

Anyway, I want to re-factor the PRISM code base so we can get too a point where it can be used with any protocol not just LFS connections from InSim, but also HTTP connections (already supported, thanks Vic), and Telnet connections (already supported, thanks Vic). I want to add WebSockets too that stack, and have all of these programs communicate through the PRISM.

Basically, the PSR-0 patch from T3 and Co would become the base for it, and we'd move all of the LFS / InSim stuff into the $PRISM/modules/lfs/ folder, and all of the HTTP, Telnet stuff into $PRISM/modules/HTTP & $PRISM/modules/Telnet. The last part would be the $PRISM/modules/WebSockets, that _might_ require the HTTP module to work, as it's an upgrade request.

From here plugins would be allowed to communicate on any protocol there was a module for. So you could have a plugin that would use the WebSocket connections and the LFS connection modules.

Note: Importing rules are per file basis, meaning included files will NOT inherit the parent file's importing rules.

<?php 
use modules\lfs\insim;
use 
modules\websockets;

class 
Multiplexing
{
    const 
URL 'http://lfsforum.net/forumdisplay.php?f=312';
    const 
NAME 'Multiplexing Example';
    const 
AUTHOR 'PRISM Dev Team';
    const 
VERSION PHPInSimMod::VERSION;
    const 
DESCRIPTION 'WebSockets and LFS InSim Connections Multiplexing';

    public function 
__construct()
    {
        
$this->registerPacket('onNewPlayer'ISP::NPL);
        
$this->registerPacket('onPlayerLeave'ISP::PLL);
    }

    public function 
onNewPlayer(ISP_NPL $NPL)
    {
        
$this->webSocket(json_encode($NPL));
    }

    public function 
onPlayerLeave(ISP_PLL $PLL)
    {
        
$this->webSocket(json_encode($PLL));
    }
}
?>

I honestly, don't even know where to start with that one. Because, I should really allow for multiple WebSocket connections. But I guess, that would be handled like multiple InSim connections, where it's agnostic too the plugin, and is a configuration setting.
Tbh, if I was writing something for the real world (so a network of servers, with a website that was live updating track maps and leaderboards) and I was using PRISM I'd probably architect this completely differently. I'd setup a plugin to ship off the events (or packets) to a pubsub system (redis most likely) and then use something else to hand off to the websockets.

I do realise that PRISM is a long running process, but it doesn't really look like PHP lends itself at all to websockets even now, and it would become a much harder problem to scale PRISM doing all of the work, imho.

Best tool for the job and all that.
I don't disagree with you, regarding the best tool for the job.

I find that PHP is severely lacking in the WebSockets space and we can fill that void with something that doesn't suck.
If it's a thing for fun, cool Smile

If it's a thing you actually think people would want and use, I suspect that far fewer people will actually use than you think...

Edit: man, that's a bad sentence.

FGED GREDG RDFGDR GSFDG