Building a channel for m2f 2.0

Hi everyone!

These have been busy days! George is finishing off MIME handling of email messages and building the general architecture that will eventually support full attachment management between channels.

I have been working in the Feed class, adding export functionality and also did some heavy refactoring to get cleaner code. There are still things to be done, in particular the configuration of the channel in the Admin-Cp, but we are almost there.

I would like to tell you a story about what’s involved in building a channel with the current state of the code (alpha 4):

• First of all, as always, you have to draw a basic sketch of what you want to do. For Feed I knew I wanted to import web feeds (mainly rss) into a forum, and export, say, latest 10 posts in a given forum out to a rss xml file.
• It is important to think whether your channel will only import, export, or both!
• Then, you build the framework of your channel, classes and interfaces, in the “lib\M2f\Module\Channel” directory. The tests will go into “\tests\lib\M2f\Module\Channel” directory.
• Then you can start building up the tests, then adding code to make them pass. You always build the test before writing actual code because it cleans up the design and also helps developing very robust code!

m2f channels revolve around objects called “Generic Messages”, which are, in essence, a data structure that holds all the information a message could eventually have. The channel converts messages from other sources such as Forums and Email into a Generic Message, or a Generic Message into a post or email message.

Having a Generic Message structure is the central approach of how m2f bind channels together. Instead of building a n-to-n format converter between channels, we decided using an intermediate format that every channel must know about.

So, for import channels, the difficulty resides in connecting to the remote software (via database link, POP, propietary API… you name it) and extracting messages in the original format. Then, convert that format into a Generic Message that can be further processed.

For export channels, the algorithm must take a Generic Message, convert it to the destination format, and finally connect to the remote software to submit the new message.

This might sound easy enough, but there are several pitfalls, including: Message threading, ugly code at the remote software side, attachment handling, weird uses cases (what happens if….?) and others. So, you have to take these into consideration if you want to develop a robust channel.

.pd