Create lmug-adptr module and behaviour

[oubiwann]

I'll look at the Ring Jetty servlet example for inspiration, and then look at what we're doing with the Elli lmug adaptor, what I've done with Barista & YAWS, what I want to do with lmug-inets, and then we should have a pretty good idea where to go with this.

[oubiwann]

A Review of Adapters/Adaptors

Ring servlet

The following public functions seem to be the crucial ones in the Ring servlet example:

• build-request-map
• merge-servlet-keys
• update-servlet-response
• make-service-method + servlet (converts hanlder to servlet) + defservice

Jetty

jetty just has one public function:

• run-jetty

but it has other supporting functions that provide useful operations, many of which make calls to the Ring servlet code.

Ring Server

ring-server provides the following:

• serve (for both the lein and standalone versions)

Previous lmug work

Barista:

• start/1 + start/2
• do/1 (inets http specific)
• stop/0

lmug-yaws:

• run-yaws/0 + run-yaws/1 + run-yaws/2
• out/1 (YAWS-specific)

lmug-elli ("develop" branch):

• elli->request/1
• response->elli/1
• handle/3

[oubiwann]

Tentative thoughts on behaviour functions (question marks are due to undefined arities right now):

• ->request/? - define a function that converts a third-party HTTP server request to an lmug request
• response->/? - define a function that converts an lmug response to a third-party HTTP server response
• handler->/? - define a function that converts an lmug handler to a function that is expected by a third-party HTTP server (e.g., for YAWS this could convert an lmug handler to an out/1 function, for inets http, a do/1 function, and I think for Elli, a handle/2 function)

Update: this recommendation owes most of its inspiration to the Ring servlet and the lmug-elli adaptor.

I think a separate behaviour could be defined for an actual lmug HTTP server (as opposed to an adaptor).

[oubiwann]

I'm toying with this, more explicit, set of names now:

(defmodule lmug-adptr
  (export all))

(defun behaviour_info
  (('callbacks)
    '(#(convert-request 1) #(convert-request 2)
      #(convert-response 1) #(convert-response 2)
      #(convert-handler 1) #(convert-handler 2)))
  ((_)
    'undefined))

[yurrriq]

Per our conversation in Slack, :+1: to lmug->* and *->lmug. convert-* feels a bit ambiguous to me.

convert-request and convert-response for now.

[oubiwann]

Okay, we've chatted a bunch about this tonight on Slack ... here's the latest update to the behaviour that worked for me this weekend:

(defmodule lmug-adptr
  (export all))

(defun behaviour_info
  (('callbacks)
    '(#(convert-request 1) #(convert-request 2)
      #(convert-response 1) #(convert-response 2)
      #(call-handler 1) #(call-handler 2)))
  (('optional_callbacks)
    '(#(set-handler 1)
      #(get-handler 0)))
  ((_)
    'undefined))

Definitely still evolving, though ...