Welcome to the Lounge

Brisingr Aerowing wrote:

On the invitations, how would those work? Through an email message? Or some other way?

• Message structrures are an issue. Even just text becomes a drag, as the standard states that quotes are placed above the message and the message ends with -- and the signature. But nearly all emails I've ever encountered have been where the message (and its signature) is above the quote instead.
• Then of course you still have those formats like HTML and RTF (though RTF seems to have died out with Outlook 2007) to contend with. Not to mention most messages would contain at least standard text in addition to one of these as a mime attachment.
• Attachments are "by standard" using mime types. But nearly all attachments through all versions of Outlook use a proprietary WinMail.dat format. And then you still get some "idiotically" old email clients using stuff like uuencode. I know many email clients (including GMail, Thunderbird, KMail, etc.) have huge issues when they've received such non-standard attachment format. And unfortunately this non-standard (at least Outlook's) has become the "de-facto" standard simply because of Outlook volumes - so you can't just say: "It's not standard, therefore I won't support it."
• You'll need to be able to import from various mail storage formats, not just using IMAP. Many users have POP accounts with local stores. So you'd need to extract historical mails from PST files, but perhaps also MailDir / MBox (depending on which other programs you're attempting to replace)
• Your local storage needs to be something easily indexable, yet also easy to archive incrementally. I.e. no single file for entire account or even entire inbox (like Outlook / Thunderbird does). You may want to try using some indexed variant of MailDir instead (something where small messages are kept in central file while large messages are saved to their own file).
• You'll need an export function, preferably catering for several formats. Though (from a previous post) I can't see CSV working well for messages (unless it's just exporting something like a message listing). For contacts / events / tasks CSV is a much used interchange format.
• Better yet would be to allow for various local storage formats instead of exporting. That way users could have live views of messages / calendar / tasks / contacts / etc. Though this is a very complicated issue - as you start entering into "client-server-db" design with such a system.
• For contacts I'd advise you look into vCard files - there's yet more issues with non-standard stuff. Some clients use custom fields or allow multi-lined fields. While others use multiple fields for stuff like multi-line addresses. I've run into this scenario before due to google's gmail contacts having their own particular flavour of vCard.
• Calendar is yet more of an issue. Yes I agree iCal is probably your best bet (though there are some others like CalDav which you might have to cater for as well). But you're going to have to make sure you understand how each format handles time zones. Some of them convert everything to UTF, while others only list what the original time zone was.
• Meeting requests and responses are also not always "standard". Especially when looking at Outlook's requests and responses. You'll have to do some trail and error on these
• Are you going to differentiate events and tasks? Or are you going to include to-do items inside the calendar? Both options have their weak and strong points.