Erlang Software Framework

I haven’t been able to code as much as I would have liked over the past two weeks due to some personal issue that came up. This puts me about three weeks behind where I wanted to be with the IMAP server and still counting.

As of this morning I have one command that I need to fully test; COPY / UID COPY. The code looks finished, but I haven’t gotten to testing it in outlook express yet.

I have one command that needs lots of work still; FETCH / UID FETCH. For anyone who followed me when I was writing the IMAP client you know how much I love the FETCH command. It is a huge command that is more complicated then it needs to be, but I think I am about 40% through it and I have the design pattern down now. It’s pretty much a matter of sitting down and and implementing the rest.

That leaves 4 commands that I am putting off till the next version; STARTTLS, AUTHENTICATE, APPEND and SEARCH / UID SEARCH . I may change my mind on APPEND and include it in this version, but I don’t think so.

After that there is still a lot of work to be done to make the IMAP server RFC compliant. At this point I am intending to make it functional and go for RFC compliance later.

I’m still working with Outlook Express as my test client and I’m hoping to have the test server working (not finished or RFC compliant) within the next two weeks.

I was working on the IMAP server this morning and I realized that I had an annoying pattern that I needed to generalize. Throughout the code I have been using the state of the FMS to figure out which is the correct store to get information from and then calling a specific command from that store. Depending on the actual process that is doing this it can take between 2 and 4 lines of code.

I started to develop an abstraction layer inside the gen_store, so that you can now call the command you are using from gen_store, giving it the data needed and the state data, and it will figure out the correct store to use to call the command from the state data.

The way the information is being processed does not change, but the way the user calls the data does. The user no longer need to figure out which is the correct store, it only calls the function from gen_store and lets gen_store figure it out. This simplifies the user process down to one line of code instead of as many as 4 and only minimally increases the size of the gen_store module. 

 I’ll be re-factoring this into the code as I go along, but I am looking forward to simplifying this task quite a bit.