[erlang-questions] Erlang Web Libraries & Frameworks

[Joe Armstrong]

On Thu, Aug 11, 2011 at 12:11 PM, Sam Elliott <sam@REDACTED> wrote:
> On Thu, Aug 11, 2011 at 10:30 AM, Loïc Hoguin <essen@REDACTED> wrote:
>> On 08/11/2011 11:01 AM, Joe Armstrong wrote:
>>> If all suppliers of web- frameworks could adopt a common adapter
>>> pattern - it would make
>>> life a lot easier. I realize that this would not allow us to use some
>>> of the finer facilities
>>> offered by an individual web-server, but it would be very useful for the simple
>>> cases of serving up files etc.
>>
>> A lot of people choose the server based on those finer facilities.
>> Adaptor projects are already used by everyone else. See below.
>
> I don't think that's much of an issue. People don't have to use the
> adapter, but where it is helpful, they have the possibility of using
> it.
>
> In a lot of cases, People don't care which library they are using,
> they just want to use one that they understand and can get started
> with quickly.

I agree fully and for this reason I think the generic adapter should offer
a simple API and come with a few simple get-you-started examples.
It should not attempt to drill down into the finer details of the individual
back-ends.

I think development should proceed as follows:

    1) start with the generic adapter
        this should be the easiest of all the interfaces to
understand and get working
    2) choose any backend
        they should all work out of the box with the generic adapter
    3) if this is not good enough change the choice of backend
        the API is the same but the non-functional behaviors might be different
         some servers replicate, load-balance etc others don't
    4) if this is not good enough use the backend native API

A casual user would start at point 1) then progress down the scale
only if and when they had problems.

/Joe
>
>>
>>> One could have a common API then choose the implementation depending upon
>>> the requirements of the application.
>>
>> This is fine and all, but some servers use lists while others use
>> binaries. The handler code is obviously different so some servers would
>> require converting everything (headers, path, ...) to lists or binary
>> before passing the data to your common handler. There's no clean
>> solution there.
>
> I think the solution is to choose some sensible defaults for the
> adapter API, then put effort into the conversion that the underlying
> implementation requires.
>
>> Some projects exist, like simple_bridge for example, but AFAIK they only
>> do lists-based servers for now.
>
> SimpleBridge (https://github.com/etnt/SimpleBridge) and EWGI
> (https://github.com/skarab/ewgi) seem to be quite close to being
> useful as an adapter, but there's still an annoying reliance on
> calling things like `simple_bridge:make_request(inets_response_bridge,
> Info)` - the abstraction only seems to wrap the request and response
> objects to provide a compatible interface. I, however, agree with Joe
> in that the abstraction needs to cover far more than that.
>
> I'll probably add SimpleBridge and EWGI to my list today.
>
> Sam
>
>>
>> What's a good solution to this?
>>
>> --
>> Loďc Hoguin
>> Dev:Extend
>>
>