How can I help? about rfc6455 HOT 6 CLOSED

That would be great @mbonneau! I'm away this weekend. First thing Monday morning I'll get my head space back into this, get a roadmap documented, and we can get this going.

from rfc6455.

Sorry for not getting back to you right away @mbonneau. I still haven't put together the roadmap as I'd like. Finishing this is something I want to complete in the near near future. In the mean time here's some high level thoughts:

• ind-spike is the latest branch I was working on
• My goal is a complete separation of concerns and to isolate state preservation to only a single place. Currently too much state is held and passed around.
• Most methods should have input and receive output except where it's not possible, but again, minimize this
• I think I hit the point where the above two came to a head and that is re-assembling the messages via onData (conceptually as this lib will not be tied to I/O)
• At this convergence point I think the method that is accepting new stream data needs to be given various callbacks as it needs to act. This point I think I was going create in the namespace Messaging\Streaming\MessageStreamer. It would need to be given things like a validator and onData callbacks for coalesced, error, etc.

High level goals that need to be reached but haven't been though out architecturally yet:

• Need to fail early on UTF-8 invalidation. Currently UTF-8 checks happen after a message has been coalesced.
• This lib should deal with PSR-7 and no longer require Guzzle (assuming PSR-7 will be accepted soon).
• The ability for Ratchet, Pawl, and Thruway to tie into control frames even when they're in between a message (ping, pong, etc).
• Support extensions
• Specifically gzip/deflate - the raw stream needs to be exposed for this, more of a React issue than here but something to consider (maybe not a goal for next release of this lib)
• Message objects should be passed to the utilizing lib (Ratchet, Pawl, Thruway) not just the payload; this will enable Binary messaging

from rfc6455.

Hi @cboden ,

I looked at this project a little bit tonight. I pushed some changes up to my fork. If you could take a look and give some feedback, that would be great.

I created a MessageStreamer that handles the websocket part of the protocol and pulled that stuff out of the Negotiator. I have it setup with event emitter (let me know if this is not what you had in mind), you can take a look at the idea here: https://github.com/mbonneau/RFC6455/blob/mb/tests/ab/startServer.php#L37

I have tried to keep I/O specifics completely out of the library itself. The data is fed into MessageStreamer::onData which causes message, ping, pong, and close events to be emitted.

It is still a bit messy as far as a user having to know too much about the protocol to use it and does not make full use of negotiation either.

from rfc6455.

Awesome work Matt! My apologies again for being slow, just started a new job. I know I won't have much time for the next two weeks, hoping after that I can dedicate time though.

I did a very quick review the only thing that stood out was the event emitter. As much as possible in Ratchet is type hinted. I would prefer something along the lines of onData accepting an interface of callback methods.

from rfc6455.

Hi @cboden ,

Are you thinking of something like this?

namespace Ratchet\RFC6455\Messaging;

interface RFC6455Interface {
    public function onMessage(Protocol\Message $message);
    public function onPing(Protocol\Frame $frame);
    public function onPong(Protocol\Frame $frame);
    public function onClose($closeCode);
}

And that would be passed into MessageStreamer?

$messageStreamer->onData($myInterfaceInstance);

If not, feel free to write an interface if you have the time and I will try to work the library to fit with that. If you wouldn't mind a code example of how this would integrate with a project, that would be great too.

from rfc6455.

@mbonneau Yup, that's what I was thinking!

from rfc6455.