MailTags to get new features
A new version of MailTags is in the pipe-line.
It will deliver an excellent and very useful improvement.
The developer Scott Morrison sent me a preview screenshot of the plugin’s new information panel:
As you can see, MailTags 1.2 will feature synchronization with iCal.
Scott writes, “I have most of it done.”
“It works so that if you change the event in iCal (change name, complete status, due date, etc), MailTags will update it in Mail when you revisit the message.”
This is exactly the kind of integration between iApps that works for me (compare CRM4Mac).
Now you will be able to create an iCal ToDo from a message while you are looking at it. No cutting and pasting, no AppleScript.
With MailTags 1.2, Mail.app users will be one step closer to enjoying the seamless interaction between iCal, Address Book and Apple Mail that makes it an even more serious alternative to Entourage.
It will also make MailTags an even more valuable tool for “Getting Things Done” (
Scott adds, “I will get this with bug fixes and the universal version out as MailTags 1.2 hopefully in the next 2 weeks.”
MailTags 1.2 is going to make a real difference to the way I work with Mail.app. I’m looking forward to it.
When 1.2 is released, you will be able to get it from Scott’s web site.
Tags: Apple Mail, applescript, gtd, iCal, integration, mail.app, mailtags, synchronization, todos, universalRelated posts
January 21st, 2006 at 12:27 pm
What about IMAP support in MailTags 1.2 ??
Is there some improvements ?
Thanks and congratulations for the blog.
What a great job !
January 22nd, 2006 at 10:02 am
Unfortunately full IMAP support is a big nut to crack and Mail’s IMAP support is a little shaky to begin with — I am working on it but things have to happen in stages.
Scott
January 30th, 2006 at 5:31 pm
Is the full IMAP support a tough nut to crack just because MailTags is built on top of Apple Mail, and Apple Mail’s IMAP support is shaky to being with? Or is there a fundamental problem with using IMAP keywords?
I know that other applications (PINE, for example, though Thunderbird has weak IMAP keyword support) are able to store whatever IMAP keywords you like. I don’t know if IMAP keywords have a length restriction, but if they didn’t, it seems like you could encode all of the MailTags information as a big (base64-encoded?) IMAP handle.
Even if that’s not possible, if one day you can configure Apple Mail to actually hide some mailboxes, you could store a mailbox with configuration data in it. This mailbox could store a list of all of the information about every message. Then each message just has to store an IMAP tag linking it to that configuration data. On top of that, the configuration data would be hidden from the mailbox list (assuming an “unsubscribe” feature will someday be built into Apple Mail) so everything would be transparent. Is that a viable solution?
January 30th, 2006 at 5:59 pm
You have me by the short and curlies there.
I don’t know. I couldn’t programme my way out of a wet paper bag.
The developer Scott Morrison happens by here from time to time. He ought to know. He’ll be busy with the new MailTags beta, but perhaps he’ll give you an answer.
January 31st, 2006 at 5:33 am
Hi Ted
A couple of things IMAP keywords are that
* Not all IMAP servers implement them (which would lead to ambiguous support)
* keywords are essentially arbitrary named flags such as /project1. This is problematic for MailTags in that it can deal with spaces elegantly, and things such as due date and notes are out of the question. I would be hesistant to deal with only some metadata and not others.
* really there are 2 options. -1- extensive use of x-headers and embedding the metadata in the message — which leaves some concerns vis a vis confidentiality of the actual metadata if the email is replied or forwarded
and -2- pretty much what you described — the use of x-headers to contain a mailtags ID that would refer to a message in a imap mailbox that would contain the actual data — so if the message was forwarded, the only x-header would be an uid to the data not the data itself.
Interms of working on it — it means I have to sit down and wrap my head around Mails implementation of IMAP a lot more — dealing the network i/o — (Mailtags only has to deal with message once it recieves them so network i/o is not an issue) You have to remember that I Mail is not open source so I am pieceing together how it works — it took a good 4 months of solid work to get MailTag up to the state it is, IMAP will not be instant. This is also not my day job… so — thatis the picture — However MT is open source and I do welcome collaboration — if people want to contribute great!
January 31st, 2006 at 6:12 am
Keep in mind I wasn’t making a criticism of MailTags. I was just curious about working with IMAP in the Apple Mail environment.
With regard to spaces/other characters, that’s why I was saying that you could use a standard encoding scheme to encode all of your information within some set of taggable characters.
I didn’t think about the problems reverse engineering Apple Mail.
It’s interesting to me that Apple Mail doesn’t provide a way to access keywords on a message. It uses IMAP keywords to do its junk handling. You would think it could come up with a nice transparent way to handle keywords (try server keywords, try server x-tags, try client x-tags) and simply pass you a vector of keywords that you could read. Likewise, you’d think you could pass it back a vector of keywords that you wanted to set. To me (and maybe I’m missing something) that seems like a very logical feature for a scriptable mail application and if Apple Mail doesn’t provide it, they should be nudged to do so.