search

zostay / RakuWAPI

The Web API for Raku (RakuWAPI)
Artistic License 2.0
24 stars 5 forks source link

Consider using an application registration routine #21

Closed zostay closed 9 years ago

zostay commented 9 years ago

In order to handle configuration that may need to be passed to the application server prior to invoking the application, I am contemplating the addition of a special, optional subroutine that may be used to configure the application:

sub app(%env) { ... }
sub register { &app, %options }

Whether a P6SGI script is returning an application or a register function is determined based on the arity of the routine. If the arity is 0, it's the registration method. If the arity is 1, it's an app. (There might be a better detection mechanism.)

The register routine returns a 2-element capture/list. The first element is the application subroutine and the second is the configuration for that subroutine.

Options I've thought of so far may include the following (but could really be extended like the environment for per-server extensions and such). Honestly, this is the sort of thing that might explode into lots of options.

'p6sgi.protocols' => ('HTTP/1.0', 'HTTP/1.1', 'HTTP/2', 'WebSocket/13'),
'p6sgix.ws.subprotocols => ('xmpp'),

As I see it, the protocols option lists the protocols the application expects to support. The server has to support at least one of the options or you have an error. There would need to be a matching p6sgi.protocol variable in the environment to inform the application which protocol has been negotiated by the server.

The subprotocols extension is a WebSocket specific setting, which tells the server that it should allow the named subprotocols in the Sec-WebSocket-Protocol header during ordered by preference. Again, this would need something liek p6sgix.ws.subprotocol to inform the application which actual subprotocol was selected.

The downside to this, which I still want some thought put into is the fact that we might want to support certain protocols sometimes and not others. This just turns it on for all, so that's not right yet, but to make multi-protocol handling not totally suck, something like this may be needed.

zostay commented 9 years ago

Let's not do this. I don't think this sort of communication is needed and if it is, it's going to be an administrative detail rather than an application detail.