Day: October 15, 2006

I moved “the saving of mime parts” out of the tinymail framework. Examples of mime parts are the attachments of an E-mail.

I did this because the user interface for “saving them” will be application specific: your E-mail client might want to use a popup menu for telling the user “this is how you save this attachment”. But this other E-mail client might use the menu invoked by the left-top button on your cellphone. You know, the one above your “call” button.

If tinymail would implement a TnyMsgView by using a popup menu for this, it wouldn’t be possible for (for example) a vendor like Nokia to use that component on cellphones. Unless of course they would hack a gtk-type like the menu. Else they would be forced to fully implement a message view. While that, because everything in tinymail for that reason is an interface, is perfectly possible, it’s not as cool as allowing the developer to inherit mine.

To prefer things like strategy and decorator (delegation) over inheritance is one of those design pattern principles. Imagine I have just received a spreadsheet file in my E-mail box. Not having a viewer for that, my phone obviously can’t view that file. Ahhh .. maybe some phones have a viewer?! But I bet those phones are more expensive. Tinymail wants to be usable on both types of phones. Tinymail is for all phones, for all mobile devices, for all embedded appliances and soon for all web applications that expose E-mail functionality. If not, that’s a design bug which you can report.

Say there would be no good reason to save it on the phone itself. Maybe the phone will someday support a virtual filesystem? I doubt that, and if it will it might not be (at all) like our gnome-vfs. In my opinion, gnome-vfs definitely isn’t the right tool for that.

I made “the saving of a mime part” a strategy that the application developer can implement himself. I have a default type for saving, implemented using gtk+. It can be inherited of course. The interface of it can, however, also be implemented. For example an implementation that does nothing or one that saves it on “myspace” in stead of on the phone. You know, by using the secret GPRS service of this “myspace” vendor.

It’s not my business how they, the phone- and this “myspace” vendor, will agree on a feature like this. This is exactly why tinymail is LGPL, not GPL. They are encouraged and allowed to keep their stuff closed. They are equally encouraged and will get my assistance to open it. But one thing is a certainty: that it’s not my business nor a decision of some opensource community to make for them.

Soon tinymail will have language bindings for programming environments like D, Java and .NET. Programming with tinymail while using these environments will look like this. Feel free to CamelCase and fix coding style yourself (it’s just an example). The links point to the tinymail framework API pieces being used. I did that just in case somebody still believes that tinymail isn’t documented.

DotNetters: #define extends :\n #define implements ,\n #define super base

public
class MyOwnMsgView extends TnyGtk.MsgView implements Tny.MimePartSaver
{
        private Button save_button;
        private Tny.MimePartSaveStrategy saver;

        public MyOwnMsgView () : base () {
                this.save_button = new Button ();
                this.save_button.Clicked = new EventHandler
			(on_save_button_clicked);
        }

        public void on_save_button_clicked (object s, ...) {
                this.perform_save (super.get_msg ());
        }

        public Tny.MimePartSaveStrategy get_save_strategy  () {
                if (this.saver == null)
                        this.saver = new TnyGtk.MimePartSaveStrategy ();
                return this.saver;
        }

        public void set_save_strategy  (Tny.MimePartSaveStrategy s) {
                this.saver = s;
        }

        public void perform_save (Tny.MimePart part) {
                this.get_mime_part_save_strategy ().save (part);
        }
}

ps. Showing and explicitly linking to i.e. its documentation is indeed my personal technique for both forcing myself to do it, and proving that I did it. Unlike most libraries and projects, tinymail is documented. Its documentation, flexibility, design and testability are the top priority of the project. And … If I say that I’ll do it, I do it. Period.