Non-Http Communication

I’m just throwing this out here, because I admit I have not done nearly enough research into it.

Web sockets are starting to rise to prominence (as part of Html5 and "Web 2.0"), which gives rise to a different way of communicating with our applications.

At the moment I am making an application for which one of the ways of interacting is through web sockets. That is to say that we first load a typical web page in the normal way, and this web page will then open a web sockets connection to continue interaction with the application (I’m not saying this is the right way of doing things, but it’s one I’m using at the moment). Following this, I find myself wanting to follow the CController way of handling things, by having the web page make a request through a web socket, to a particular controller/action, with accompanying parameters. Ideally, I want to deal with this request in the same way that I would an Http request - ie check that the route is valid, apply any filters, and check access permissions for the action, before perhaps rendering an object to be sent back to the web page (usually as JSON).

There are a few aspects to this - first the controller paradigm. At the moment, I am using the Wrench web sockets framework to handle socket communication (a fairly good implementation, that could be suitably adapted to Yii), and integrating this into a Yii console app. Console apps currently lack controllers (perhaps controllers aren’t the best way forward for it - I’m open to discussion), so I’m basically copying CController and removing/adapting those parts of it that rely on Http requests - this means doing the same thing for all those useful things like filters/access controls, which may partly rely on the Http request.

Now, it seems to me that we should have a more abstract base controller (outside the web section, and even adding controller support in CApplication in the same vein as for CWebApplication) upon which we could base the normal web CController (maybe CWebController), but also a CConsoleController, allowing us to reuse code which is basically the same, while adding in later the specificities of the connection type (and do the same for CFilter etc).

We could also have different user and session components (or rather a more abstract base, with child classes for different connection types) - obviously a web sockets connection stays open, and only needs authenticating once, but also for web sockets, one application instance will contain many connections (and user instances) at the same time, so user actions should be processed with the individual connection authentication each time.

Sorry if I am not being clear about this - I have perhaps rambled a bit.

Basically, I think it might be good to make more abstract base controllers (and application components) that are independent of the connection protocol, to allow us to keep base logic separate and reusable before deriving the Http ways of handling connections.

What do people think about this?

Console apps in Yii2 are now the same as web apps i.e. using controllers. And we have base Controller not tied to any specific environment.

In which case I needn’t have rambled nearly so much

That sounds like just what I was looking for.

Can we perhaps imagine some form of user component (with a common base for web and console) that can take into account the fact that there may be many different users connected at once in a console app, rather than the single user scenario of a web app? With perhaps a custom session type component to tie arbitrary data to a user session.

Well, I don’t think we’ll support single instance, many threads out of the box but there will be even less obstacles to use Yii like so than in 1.1 (yes, some people are using Yii like that and I saw it in production).

I wasn’t talking about multi-threaded applications, just simple single-threaded applications where many users can be using the one application instance at any given time - my scenario here is a web sockets server running, which can accept connections from many clients, so the main application will have an array of connections, with each connection potentially representing a separate user for whom different access rights should be applied when running actions on controllers.