[erlang-questions] Is Erlang a good tool for this particular project?

[Matthew Hillsborough]

Greetings Erlang community,

Let me further elaborate on my question that's in the subject of this
message. I tried to reach out with this question on StackOverflow, however I
did not have much luck there. Perhaps the community here can provide some
feedback here for me to let me know if I'm on the right track or if Erlang
is not the right tool for what I'm trying to accomplish.

   I'm building native mobile applications in both iOS and Android. These
apps require "realtime" updates from and to the server, same as many (but
not all) network-based application does (Facebook, social games like Words
with Friends, Finance applications, etc). The communication here is
bi-directional, in the sense that the server might have updates for the
mobile clients and the clients will be pushing data down to the server
whenever necessary.

I think using HTTP long polling for this is over kill in the sense that long
polling can be detrimental to battery life, especially with a lot of TCP
setup/teardown for every HTTP connection the device needs to send out
through the wire. It might make sense to have the mobile applications use
persistent TCP sockets to establish a connection to the server, and send RPC
style commands to the server for all web service communication. This
ofcourse, would require a server to handle the long-lived TCP connection and
be able to speak to a web service once it makes sense of the data passed
down the TCP pipe. I'm thinking of passing data in plain text using JSON or
XML and then using some kind of Erlang interface to HTTP to call a web
service to handle all the REST type communication. The responses would then
go back to the "RPC" Erlang instance, which would send the updates to the
appropriate client(s).

Perhaps an Erlang based RPC server would do well for a network based
application like this. It would allow for the mobile apps to send and
receive data from the server all over one connection without multiple
setup/tear down that individual HTTP requests would do. Since no web browser
is involved, we do not need to deal with the nuances of HTTP long-polling at
the mobile client level. I also haven't seen great long polling/keep-alive
support on the client-side in iOS, but that's irrelevant for the community
here.

A lot of these "COMET" and long-polling/streaming servers are built with
HTTP in mind. I'm thinking just using a plain-text protocol over TCP is
better catered for the type of app I'm building, will make the client more
responsive, allow for receiving of updates from the server without
constantly polling the server, etc.

I also looked into HTTP pipelining, but it doesn't look to be worth the
trouble when it comes to implementing it on the clients. Also, I'm not sure
if it would allow for bi-directional communication in the client<->server
communication channel.

Am I completely out of line in thinking that building a custom solution in
Erlang is a good idea here? To my understanding, Erlang excels at servers
like this, and if I run the server on tcp/80, I should be able to avoid most
firewall/port issues. The client would need work to deal with timeouts, re
connections, acknowledging receipt of asynchronous requests, but that's not
Erlang's problem.

Has anyone built something similar before? Should I just stick to a web
server and deal with "COMET" type technologies? (WebSockets, long-polling,
client-side polling).

Was hoping someone could solidify that I'm not entirely insane for wanting a
better solution than HTTP would serve in this case, at least at the client
level. I'll still be using HTTP/REST extensively, the Erlang server would
just handle the persistent connections and messaging to the Web Service
(which would probably be something like Django or Rails).

Sorry for the long post; I am just excited to get into the heads of people
who are smarter than I.

Happy hacking!

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110712/435f078d/attachment.htm>