Mark McCullough wrote: > On 2009-10-23 22:40, Brandon S. Allbery KF8NH wrote: > >> On Oct 23, 2009, at 23:29 , Joseph S D Yao wrote: >> >>> Or get a separate calendar. I mean, who first thought to put a calendar >>> into a MAIL program, of all things? >>> >> Anyone who schedules meetings via email. >> > > Following the Unix approach of do one thing and do it well, I prefer > that these be separate tools that integrate well. Just because an > invite might show up as a message in my inbox doesn't mean that the mail > program should be responsible for maintaining the calendar. Maybe I've > drunk too much Apple kool-aid, but I find I like the way iCal, Mail, and > Addressbook are three separate programs that seem to talk to each other > well. This has the added benefit of I could replace the front end of > one of these programs (say calendar) and still use the same backend to > hold the calendar. > > I'm sorry but the analogy doesn't quite hold up if you consider 'transport' mechanisms versus 'consumers of transport mechanisms'.
You can certainly have separate email and calendar client programs and still use RFC-821/822/etc messages as a transport mechanism, in the same way that you can use ssh as a terminal service, a file transfer transport, and even a filesystem access transport (sshfs rocks! Works to Windows boxes too!!! :-). There's nothing inherently wrong with using the mail system as a calendaring transport, and there are actually some reasons why it made some sense. Not everyone has a calendaring program, or they may use a calendaring system with a different (and possibly also proprietary) protocol. By using email as the transport medium, and putting the calendaring messages into mostly-human-decipherable form, people can use Exchange calendars to invite non-Outlook/Exchange users to their meetings. It would even be possible for foreign calendaring systems to accept the email message and translate them into their own native form. Now, do I think that Microsoft did a good job of using email transport for calendaring? Not really, as the delivery and acceptance mechanisms are nondeterministic at the calendaring level, but I've learned how to tame the beast. With a few server-side Exchange rules, calendaring rarely gets in the way of my email - with a side effect (intentional) of keeping a copy of the calendaring messages in my inbox so that I know that I have meeting invites to deal with in my calendar. I prefer Thunderbird over Outlook for email, so I use Thunderbird with IMAP for my email. However, for full calendaring functionality only Outlook will do, so I keep a copy of Outlook fired up in a Windows VM for those calendaring duties that can't be done (yet) via the web or other non-Microsoft-proprietary interfaces. I need Windows for certain other programs that don't have an equivalent in the *nix world, e.g.., Visio and Powerpoint (I use Open Office for most things, but it mangles complex PowerPoint docs -and even some Word docs - that I have to work with) so I don't have problem with having an Outlook client running there for calendaring. I'm an 'OS gourmand' anyway - I aim to use the best tool for job, and that means that I typically need both Linux and Windows desktops available. I do this at work and at home to cover the full range of tools. I'll be adding Mac back into the mix soon. I haven't had a Mac since the OS 9.x days, but I'm looking forward to one as my next work laptop - and I will have VMs for Linux and Windows on it as well - again, to get the full range of tools at my fingertips. My point - this shouldn't be about using either/or, but instead - *every* OS. And as highly intelligent tool users and builders we should be the ones who help people make the most use of whatever tools are available, including finding ways to make Linux users happy when they are required to use an Exchange mail server in a way that looks 'Linux native', and to make Linux resources fully available to Windows users - in a way that appears to be 'Windows native'. And this goes double for smartphone interfaces. Discuss. :-) - Richard _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
