Erlang Software Framework

ErlDir will be the package for holding the DNS and LDAP protocols and a few miscellenaous pieces that don;t quite fit in other places.

I already have the DNS packet encoding, decoding, compression and decompression routines written for the DNS server. I’ve even done some very simple communications work with it, although since DNS is based on UDP instead of TCP I’m still in the process of learning what the correct communications patterns are.

I’m planning on the DNS server being an authoritative and a caching DNS server along with the capability of doing DNS based black lists to enhance ErlMail.

The LDAP server will be using the built in ASN.1 modules (Thank you Erlang) for most of the hard work. The rest is mostly writing the data storage and communications. I intend that the LDAP server will become the central repository for many different type of information through all the applications that use the Erlang Internet Framework.

I personally plan on using LDAP for the user and configuration information for ErlMail and ErlWeb which will simplify the process of creating, removing and changing users that will use a web based email client.

Erlang, ErlDir, DNS, LDAP

Technorati Tags: Erlang, ErlDir, DNS, LDAP

ErlWeb is the package that contains the HTTP and FTP protocols and a few other goodies.

The HTTP protocol will be served by the Erlang Web Server (EWS) which is going to be an HTTP/1.1 compliant web server with as many standard extension as I can mange to create. I already have the scanning and parsing routines down for HTTP messages and I have the base code done for the communications side as well.

While all of that can be used now with the built in HTTP server and/or YAWS the part that is motivating me to create EWS is a built in markup language that I am developing called Erlang Markup Language (ERML). This language will be similar to other markup languages like HTML, but it will have the scripting capabilities of a server side language and be extendable by any erlang module on the system.

ERML will be compiled into BEAM files so that they are easily run by any Erlang system and a caching system will detect when a file has changed and it will re-compile the file into a new BEAM file and reload the newer version into the system. This will allow for easier updating of web sites and faster development times.

I believe that ERML will eventually create a group of programmers that know how to use ERML, but may not know how to write programs in Erlang. This will hopefully expand the overall Erlang user base and open up new markets, including writing Erlang modules that are specifically meant to be used in ERML web based applications.

I have written two prototypes of the scanning and parsing routing for ERML and I’m not quite happy with them yet. I have extensive notes on how the languages is going to be implemented and I just need to find the time to create it

Erlang, ErlWEb, ERML, Erlang Markup Language

Technorati Tags: Erlang, ErlWEb, ERML, Erlang Markup Language

The one application that I have the most work done for in the Erlang Internet Framework is ErlMail. ErlMail is going to be the full email server that covers SMTP, POP3 and IMAP4. Creating both client software and server applications for all of those protocols.

I already have an SMTP client and an IMAP4 client that I built as part of my Spam Free Email project and I will be uploading some of those files to this site in the near future.

I had been using the IMAP client and the SMTP client as part of my web based email application that I had been writing using YAWS. The application was coming along quite well until I decided to create my own web server and I lost my inspiration to work with YAWS anymore. I want to make it perfectly clear that I think YAWS is a great web server, but I have some specific ideas that I want to implement that I could not see a clean way of doing with the framework they had setup. But I digress …

It is my intention to create ErlMail with the performance and usability of qmail, sendmail or MS Exchange, while making the configuration and maintenance as simple as possible and including the native concurrent and distributed aspects of Erlang in the process.

The ability to have a distributed email store on a network drive along with implementing users inside of either mnesia of an LDAP server would allow for as many servers as you wanted to be added or removed based on your current needs. Although those are features that are either inherent to Erlang or I plan on implementing then through the EIF.

That is good enough for now, I’m sure I’ll be wanting to describe more of this as I work out the features and bugs. 

Erlang, ErlMail, SMTP, IMAP4, POP3

Technorati Tags: Erlang, ErlMail, SMTP, IMAP4, POP3

I have been programming in Erlang for the better part of two years now. I’ve written a few servers that I use internally and some tools that I personally find invaluable. Each one of my own projects seems to be isolated and while they play nice with other Erlang applications I haven’t seen a consistent flow from my own software, even though it is OTP compliant.

Most of my work with Erlang has been building communication applications, specifically for email. (SMTP and IMAP) I’ve found Erlang to be a fantastic language to work with on communication applications and I wanted to take my projects one step farther.

To that end I have given myself the task of writing most, if not all, of the core Internet servers in Erlang in a form that is designed to work together or as individual servers. This project will include (but isn’t limited to) DNS, LDAP, SMTP, POP3, IMAP4, HTTP and FTP.

I know that many of these servers have already been written and I have personally written at least one of them myself (SMTP) but my main goal for this project will be consistency and compatibility.

By compatability I want each of the separate servers to have access to and use of many of the modules from other servers. Most notably would be several scenarios:

1. SMTP, IMAP4, POP3 and LDAP: When using an LDAP server for user authentication the different servers that are part of an email system can use the LDAP server to verify the users.
2. HTTP, SMTP and IMAP4: When designing a web based email application the IMAP4 and SMTP protocols can be used from within their own servers to extend the web server.
3. HTTP and LDAP: Another user authentication method as well as storing user information for later use.
4. SMTP and DNS: It would be possible for the DNS server to access information from the SMTP regarding what IP Addresses are known for sending spam and create a DNSBL from that information.

While all of these scenarios can be accomplished now, to my knowledge none of them are being done in pure Erlang. This is the intention of my creating the Erlang Internet Framework.

Erlang, SMTP, IMAP, POP3, DNS, LDAP, HTTP, Erlang Internet Framework, EIF

Technorati Tags: Erlang, SMTP, IMAP, POP3, DNS, LDAP, HTTP, Erlang Internet Framework, EIF