[erlang-questions] Erlang Web Libraries & Frameworks

[Joe Armstrong]

On Thu, Aug 11, 2011 at 11: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.
>
>> 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.

Right, that's why an adaptor is useful. I suspect the differences
by accident rather than design. I would assume the "natural" way to
transfer large blobs would be as binaries, and to communicate parsed
attributes would be a Key-Value proplist of strings and so on.

Having a well defined adaptor interface might have beneficial side effect
of causeing the sofwtare at either side of the interface to migrate
towards a set
of common types in the interface.

>
> Some projects exist, like simple_bridge for example, but AFAIK they only
> do lists-based servers for now.

I hadn't heard of simple bridge until you mentioned it - it looks
pretty much to be what I wanted.


@sam - can you add simple_bridge to your list (its at
https://github.com/etnt/SimpleBridge)

I wonder how many other adaptor patterns there are: if simple_bridge
is the web adaptor
where that the adapters for key-val databases?

(( aside -- it is a source of never ending frustration that the
interfaces to ets and dets are different
   getting people to change ets or dets is very difficult since we
don't want to break old code
   but an adapter would do the job ))

> What's a good solution to this?

I don't know - I suspect good interfaces emerge. It's often not
apparent at the start of a project what
the best API is. We can't abstract over several interfaces until we
have several interfaces.
Once the problem is well understood and we have several implemenations
we can begin to
generalize and abstract out what should have been the interface. Then
we have to refactor our programs.
(( This is the 99% hard-work part - software gets continually polished ))

/Joe


> --
> Loďc Hoguin
> Dev:Extend
>