[erlang-questions] Erlang http servers

[Dale Harvey]

"The standard library is where modules go to die"
http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/
This is from python world, and is very obviously seen in Erlang.

Alternatively https://npmjs.org/ has 15k+ packages, we dont need to add
user management and the kitchen sink to inets, we need to remove it from
the standard library and promote userland packages as first class citizens
(ie pick a tool to install packages and bundle it)

On 1 October 2012 13:57, Fred Hebert <mononcqc@REDACTED> wrote:

>  I did not have much to say about the rest (except that different
> interfaces may emerge based on the use cases that the server optimizes
> for), and I mostly nodded in agreement to most of your points, but the last
> one I believe is a very bad idea.
>
> This is a problem in terms of:
>
>    1. *Maintenance*. You don't want to usually give such an obvious
>    window into your server as it somewhat crystallizes your internal
>    application as a public API, what the URI is usually used for. We should
>    strive to have URIs never change (see W3C - Cool URIs don't change<http://www.w3.org/Provider/Style/URI.html>). Unless you're ready not to change the function calls under the hood, I
>    would not use this.
>     2. *Security*. How do you keep someone from calling
>    http://some.host/erlcall?mod=init&func=stop or
>    http://some.host/erlcall?mod=os&func=cmd&arg1="rm -rf /" ? If you go
>    look at tryerlang.org's repository, you'll see how restrictive Roberto
>    Aloi had to make it to avoid people doing tricky things like passing
>    binaries of funs calling things they shouldn't indirectly just to crash the
>    system. This is absolutely non-trivial as soon as you move out from using a
>    very restrictive white list of valid functions -- at which point you may as
>    well hide them behind URIs.
>    3. *Clarity*. What are the argument types? Should we treat the '111'
>    as a string? a binary? an integer? An IO List? Should the server force all
>    arguments to be of a given type that needs to be converted later so you
>    need to have some kind of intermediary function doing conversion for you?
>    It's not different from what we get right now, but there's a difference in
>    expectations from the developer. A minor issue, I guess.
>    4. *RPC and HTTP*. Whether RPC is still a good way to do things is up
>    to debate (look for Steve Vinoski's essays and posts on the topic).
>    Shouldn't the erlcall URI be extended to also handle timeouts? Or are these
>    server options unrelated to the function call? More than that is the idea
>    of how you write things that may depend on content-type (such as RESTful
>    web services). For example, a browser that sends a request to a page in
>    HTML may be served HTML. If Javascript asks for info in JSON, then the same
>    URI may forward JSON. There is an out-of-URL mechanism to deal with
>    different requests and ideas.
>    5. *HTTP Spec problems*. GET and HEAD requests should be idempotent.
>    PUT, POST, and DELETE can be used in ways that change information on the
>    server. If I use POST to
>    http://some.host/erlcall?mod=foo&func=bar&arg1=111 and it updates
>    data, what should it do when I use GET or HEAD on it? Do we prefer to use
>    the POST body for the requests that are done under the POST method? What if
>    I include both POST arguments and querystring arguments and they are
>    different?
>    More than that, HTTP doesn't specify what happens when you have more
>    than one querystring argument being the same (from memory). It should thus
>    be possible to have arg1 four times in the URL, with arg3 being there
>    only once, and arg2 being entirely missing. Same with the module or
>    function name. How do we make this interface behave at that point? Things
>    are way more complex than what they look like.
>
> There are likely more issues with this approach. Ideally, it should be
> impossible for the user of your server to know what you used to implement
> it -- this is what should give you the most freedom in terms of
> implementation when lots of people start using it. At this point I'm
> thinking we should start using different protocols from HTTP if we're not
> really willing to respect it, but that's for another discussion.
>
> And yes, more user management would definitely be nice. I've written a
> tiny library to handle passwords themselves, but it's not close enough to
> be something a framework would use without surrounding support -- it just
> handles the core of password hashing and verification. It's currently
> hosted at https://github.com/ferd/erlpass . Then each platform such as
> Zotonic likely reimplemented their own, although I don't know how moveable
> they are outside of the project.
>  Regards,
> Fred.
>
>
> On 12-10-01 4:01 AM, Joe Armstrong wrote:
>
> On Sun, Sep 30, 2012 at 11:29 PM, Serge Aleynikov <serge@REDACTED> <serge@REDACTED>
>  wrote:
>
>
> It would also be highly desirable to standardize the relationship
> between a http uri and
> and erlang function call.  For example
>
>
>      http://some.host/erlcall?mod=foo&func=bar&arg1=111
>
>
> means call foo:bar(...) on the server and return the value as html (or
> something)
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121001/c0c68cec/attachment.htm>