<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
This is a problem in terms of:<br>
<ol>
<li><b>Maintenance</b>. 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 <a
href="http://www.w3.org/Provider/Style/URI.html">W3C - Cool
URIs don't change</a>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
). Unless you're ready not to change the function calls under
the hood, I would not use this.<br>
</li>
<li><b>Security</b>. How do you keep someone from calling <tt><a class="moz-txt-link-freetext" href="http://some.host/erlcall?mod=init&func=stop">http://some.host/erlcall?mod=init&func=stop</a></tt>
or <tt><a class="moz-txt-link-freetext" href="http://some.host/erlcall?mod=os&func=cmd&arg1=">http://some.host/erlcall?mod=os&func=cmd&arg1=</a>"rm
-rf /" </tt>? 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.</li>
<li><b>Clarity</b>. 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.</li>
<li><b>RPC and HTTP</b>. 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.</li>
<li><b>HTTP Spec problems</b>. 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 <tt><a class="moz-txt-link-freetext" href="http://some.host/erlcall?mod=foo&func=bar&arg1=111">http://some.host/erlcall?mod=foo&func=bar&arg1=111</a></tt>
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? <br>
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 <tt>arg1</tt> four times in
the URL, with <tt>arg3</tt> being there only once, and <tt>arg2</tt>
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.<br>
</li>
</ol>
<p>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.<br>
</p>
<p>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
<a class="moz-txt-link-freetext" href="https://github.com/ferd/erlpass">https://github.com/ferd/erlpass</a> . Then each platform such as
Zotonic likely reimplemented their own, although I don't know how
moveable they are outside of the project.<br>
</p>
Regards,<br>
Fred.<br>
<br>
<div class="moz-cite-prefix">On 12-10-01 4:01 AM, Joe Armstrong
wrote:<br>
</div>
<blockquote
cite="mid:CAANBt-rz6A9Xdnv78=kdPWMQdZQ0N60J=wOx6DO22kG9CjuOWg@mail.gmail.com"
type="cite">
<pre wrap="">On Sun, Sep 30, 2012 at 11:29 PM, Serge Aleynikov <a class="moz-txt-link-rfc2396E" href="mailto:serge@aleynikov.org"><serge@aleynikov.org></a> wrote:
It would also be highly desirable to standardize the relationship
between a http uri and
and erlang function call. For example
<a class="moz-txt-link-freetext" href="http://some.host/erlcall?mod=foo&func=bar&arg1=111">http://some.host/erlcall?mod=foo&func=bar&arg1=111</a>
means call foo:bar(...) on the server and return the value as html (or
something)
</pre>
</blockquote>
<br>
</body>
</html>