rss_wrap_item({message, Date, From, Subject, Content}) ->
[ “<item>”, “<title>”, Subject, “</title>”,
“<description>”, “From: “, escape_from(From),
Content, “</description>”, “<pubDate>”, Date,
“</pubDate>”, “</item>” ].

This allows you to avoid the creation of a whole mess of lists.

Good job :) and have a nice day

/Mazen

Mazen: I’m glad you enjoyed the article. I know about trapexit and I like it :)

Some people at reddit noticed that the element function is used instead of pattern matching. I did it for the sake of learning - I needed to limit the amount of new concepts introduced in one example. I edited the article a tiny bit to clarify this.

Nice work though — erlang tutorial are always a good thing. :)

With all of the recent hype around Erlang (which is a good thing IMHO), I just want to make sure folks understand some of the ramifications of network programming.

“Going back to pop3, the general pattern of communication will be not too surprisingly Request -> Response, so maybe we can capture a higher level abstraction… Actually, we also don’t have a guarantee that the response will come in one portion (hence one ssl:recv), so we need to pull data out of the socket until we reach a CR/LF at the end”

In the http server, through, I didn’t want to work through the same thing again. Since the data pulled out of the socket is accumulated, a “GET /” is caught even if it arrives in more than one packet. But as with the other comments, this is a great place to point out or emphasize things like that. Thanks!

Amr: I will try to provide it soon.

So how do I get this up and running so that I can subscribe to my Gmail-RSS in my Google-Reader?

Thank you!

Zeno

c(message).
c(pop3).
c(http).
c(rss_wrap).
c(gmailrss).

Now you can run the thing:

gmailrss:main().

As Google Reader is a web application, so I believe it won’t work with “http://localhost/” as the feed address - you need to supply it with your IP or domain name, accessible from the web. The problem with this is that everybody will be able to read the feed, and thus the contents of your email account, I don’t know if there is a way to do some sort of authentication. With a local feed reader, you can just run it on 127.0.0.1 (by changing the gen_tcp:listen in the http module a tiny bit) and don’t care about that.

Anyway, if this was meant for production use, I would change a few things and add a bit more error handling…

That said, I have a couple of comments:

1) I want to second dizzyd’s suggestion that the string concatenations are unnecessary and (actually) bad Erlang style. Simply creating lists of strings and flattening them when necessary is better style.

2) In the pop3 module, you can make the connection to the POP3 server line-oriented by setting the property ‘{packet, line}’ in the gen_tcp:connect() call. This simplifies the code that processes responses from the POP3 server, because you don’t need to keep looking for “\r\n” sequences.

3) The message module is adequate for what you’re using it for here, but mail headers can’t be parsed like this in general, because header fields can span multiple lines. It takes very little additional code to create a robust message parser that handles multiline header fields correctly.

4) It would be useful and instructive to add the code necessary to shut the htp server down cleanly. (I think that with your example, you actually need to shut down the entire Erlang node to terminate the http server.) There are probably different ways of doing this, but added a ’stop -> exit(stopped);’ clause to the ‘receive’ statement for the control_server() and added a line to the http:initialize() function to link it to the control server process.

I think it would be nice to have a followup article in which issues like these were addressed and the entire project recast as an OTP application. But, again, thank you for this article; it would definitely get my vote as the winner of Dave Thomas’ Erlang blogging challange.

control_server(Response) ->
receive
{set, response, NewResponse} ->
control_server(NewResponse);
{get, response, Pid} ->
Pid ! {response, Response};
_ ->
control_server(Response)
end.

Shouldn’t the control_server loop after a “get”? Something like this:

control_server(Response) ->
receive
{set, response, NewResponse} ->
control_server(NewResponse);
{get, response, Pid} ->
Pid ! {response, Response},
control_server(Response);
_ ->
control_server(Response)
end.

Great tutorial on Erlang (the first that I read)!