In a move that's sure to help all of the iFolk in their iLives, Apple has announced improved calendaring support in Leopard, the new version of OS X. They've improved the client- and server-side calendaring support, including announcing support for CalDAV. At the same time, Apple has announced it is joining The Calendaring & Scheduling Consortium. They offer a sneak peek at all of this, too.
Apparently, at least one major vendor of software used at home (sorry, IBM but I don't see much of Notes on home desktops) has come to the realization that we really, really want our calendars to work together, and not just with calendars on other OS X Machines, and they're taking steps to get there.
Microsoft? When are you gonna join? I know you're working on calendar stuff; but it would be nice if you participated in the organizations with your peers, too!
CalDAV and the Consortium are great examples of how vendors can win by cooperating; we the consumers just want our stuff to work across the net without wondering what the other guy has, CalDAV is one way to do that.
To quote: "All we are saying, is give peace a chance"
Tuesday, August 08, 2006
Saturday, July 22, 2006
Calendar Interop Demonstrated in Miami
For those few of you that read this blog for calendaring info, let me point you to this entry at Calendar Swamp. Scott Mace reported on a demonstration for The Open Group of free/busy interoperability. This was done by The Calendaring & Scheduling Consortium using CalDAVwith participation of several member companies.
Read Scott's post and his links to other documents for the details.
Read Scott's post and his links to other documents for the details.
Thursday, April 13, 2006
Google Calendar arrives
It appears the long-rumored Google Calendar is here. The overview looks good - but the proof will be in how well it handles the everyday things we all want to do with Calendars. Wonder if they will participate in CalConnect interops now?
Update Due to various projects at work and home, I probably won't be able to play with Google Calendar very much; what I've seen looks okay. As with practically anything else done by Google, there are a googol of blogs covering it - so I don't think you'll miss my commentary very much.
Update Due to various projects at work and home, I probably won't be able to play with Google Calendar very much; what I've seen looks okay. As with practically anything else done by Google, there are a googol of blogs covering it - so I don't think you'll miss my commentary very much.
Monday, March 27, 2006
A Modest Proposal
This post describes some issues they're having because some Australian states decided to delay Daylight Savings Time a week, but apparently nobody told their Exchange server(s). Not a huge deal really - some meetings may be off nu an hour for that one week - but it does bring up the issue of how timezones are a real pain in the calendaring world.
You can read elsewhere about the timezone issues, about there being no standard (NIST, IETF, ISO, ANSI, or otherwise) for timezones, and about there not even being standardization in one country (there was a fairly funny "West Wing" episode where two supposedly brilliant guys miss their plane because they're in a part of the US which doesn't do the daylight saving time thing). You'll quickly wonder why we let ourselves get in the mess we are in with timezones.
The answer? We let the political bodies get involved in determining where timezones begin and end, and whether to participate in daylight saving time changes. So instead of having a set of evenly divided timezones, like orange slices, we have a larger set of irregular pieces, with different rules and regulations apply to each as far as when to switch to an hour ahead or behind, or not - however their voters see fit.
It is high time for some international body to hold a meeting, and declare that henceforth we're all going to use one set of regular timezones, without adjustments for daylight savings time to mess us up twice a year. The question is, how to define them?
A lot of people would probably go for 24 zones, 15 degrees of longitude each. That's a simple case, but each zone is then over 1000 miles wide at the equator. That means that there's quite a bit of variance between solar noon (when the sun is directly overhead) and the noon on the clock. The east end of the zone is approximately 30 minutes behind solar noon, and the western end is 30 minutes ahead.
If I had to have timezones, I'd propose that we do 96 zones which are 3.75 degrees of longitude wide. The center of each zone would be 15 minutes from the zone to either side of it, and a zone would be approximately 250 miles from side to side, which is large enough to encompass most states, cities, townships, or what have you.
I have, however, a more radical proposal - do away with timezones entirely. Everyone set their watch or the time on their computer or whatever to UCT, the time at the Greenwich Meridian, and just adjust your thought processes - in most of Florida, for example, we'd get used to going to lunch at 17:00 and getting off work at 22:00. The times we use are just arbitrary names for one part of the day, anyway; they're probably all based on concepts like "noon" - everyone has a local "noon" when the sun is overhead, but you can call any clock time you want "noon", everyone will know what you mean.
This would have its opponents, especially in the US where we haven't even gone to the metric system yet (why the world's most scientifically innovative country can't seem to work in base 10 is a mystery to me) - but it would sove a lot of other issues and it would definitely make the calendar software folks happier!
While we're warping time (not space) - realize this would get rid of Daylight Saving Time too - which just modifies the local referents for what time it is: "noon" moves to a different point in the sky because somebody said so. I won't miss it when it's gone.
You can read elsewhere about the timezone issues, about there being no standard (NIST, IETF, ISO, ANSI, or otherwise) for timezones, and about there not even being standardization in one country (there was a fairly funny "West Wing" episode where two supposedly brilliant guys miss their plane because they're in a part of the US which doesn't do the daylight saving time thing). You'll quickly wonder why we let ourselves get in the mess we are in with timezones.
The answer? We let the political bodies get involved in determining where timezones begin and end, and whether to participate in daylight saving time changes. So instead of having a set of evenly divided timezones, like orange slices, we have a larger set of irregular pieces, with different rules and regulations apply to each as far as when to switch to an hour ahead or behind, or not - however their voters see fit.
It is high time for some international body to hold a meeting, and declare that henceforth we're all going to use one set of regular timezones, without adjustments for daylight savings time to mess us up twice a year. The question is, how to define them?
A lot of people would probably go for 24 zones, 15 degrees of longitude each. That's a simple case, but each zone is then over 1000 miles wide at the equator. That means that there's quite a bit of variance between solar noon (when the sun is directly overhead) and the noon on the clock. The east end of the zone is approximately 30 minutes behind solar noon, and the western end is 30 minutes ahead.
If I had to have timezones, I'd propose that we do 96 zones which are 3.75 degrees of longitude wide. The center of each zone would be 15 minutes from the zone to either side of it, and a zone would be approximately 250 miles from side to side, which is large enough to encompass most states, cities, townships, or what have you.
I have, however, a more radical proposal - do away with timezones entirely. Everyone set their watch or the time on their computer or whatever to UCT, the time at the Greenwich Meridian, and just adjust your thought processes - in most of Florida, for example, we'd get used to going to lunch at 17:00 and getting off work at 22:00. The times we use are just arbitrary names for one part of the day, anyway; they're probably all based on concepts like "noon" - everyone has a local "noon" when the sun is overhead, but you can call any clock time you want "noon", everyone will know what you mean.
This would have its opponents, especially in the US where we haven't even gone to the metric system yet (why the world's most scientifically innovative country can't seem to work in base 10 is a mystery to me) - but it would sove a lot of other issues and it would definitely make the calendar software folks happier!
While we're warping time (not space) - realize this would get rid of Daylight Saving Time too - which just modifies the local referents for what time it is: "noon" moves to a different point in the sky because somebody said so. I won't miss it when it's gone.
Friday, March 17, 2006
Eventful and. Upcoming
Eventful and Upcoming are two very similar "event database" systems, which host event listings, allow you to add or search for events, and allow you to filter them by various criteria or tags.
I think Upcoming is pretty good, but Eventful wins in my book for one simple reason: I can click on a button in an event, or list of events, and open it in my calendar program, currently Outlook, as long as that program handles files of MIME type "text/calendar". This makes it really easy to move an event listing to my own personal calendar, which is where it needs to end up. I've only tested this on my PC - it might work on a mobile phone, if that phone's software can handle opening the file type. I'm told the PalmOS can open it, but that may only be in e-mail, and not a browser. Even so, it's very useful.
I think Upcoming is pretty good, but Eventful wins in my book for one simple reason: I can click on a button in an event, or list of events, and open it in my calendar program, currently Outlook, as long as that program handles files of MIME type "text/calendar". This makes it really easy to move an event listing to my own personal calendar, which is where it needs to end up. I've only tested this on my PC - it might work on a mobile phone, if that phone's software can handle opening the file type. I'm told the PalmOS can open it, but that may only be in e-mail, and not a browser. Even so, it's very useful.
Friday, February 03, 2006
A new calendar tool about to hit...
Via the blog of the famous Robert Scoble, I read about 30 boxes (note, the link is not open yet, apparently the public beta begins Sunday - 2/5/2006). This is an application that is a web-based, Ajax-powered calendar that allows sharing of your calendar with "buddies". Scoble points to an early review by
Thomas Hawk, which was very interesting.
Thomas Hawk, which was very interesting.
Sunday, January 29, 2006
"That's not a calendar... THIS is a calendar"
Have you noticed how many "calendars" on the 'Net are really just passive representations? An awful lot of them are just HTML or PDF versions of what you used to get in paper newsletter- a static "printout" of dates and times, that isn't of any use to anything else on your computer.
On the other hand, some organizations do make an effort, providing each event with a link that causes the event to open in your local calendaring program, usually by providing a link to an iCalendar file.
The difference in usability between the two is really painfully obvious: picture yourself going to the school website of your kid, and on that website you find a link labelled "school calendar". Great, you think, I'll add all of Little Johnny's football practices to the family calendar. You click the link, only to find out that it's a PDF, and if you want to add those items, you're going to have to retype each and every one of them. Not very customer-friendly, I'd say. If they had opted to provide the "active" link to an .ics file, you could select ech of the events and add them to your calendar where they'd be most useful.
Vendors are starting to get serious about 'shared calendars" and this is a small but important step - they need to provide ways for all of the organizations in our lives to easily give us these active calendar links.
On the other hand, some organizations do make an effort, providing each event with a link that causes the event to open in your local calendaring program, usually by providing a link to an iCalendar file.
The difference in usability between the two is really painfully obvious: picture yourself going to the school website of your kid, and on that website you find a link labelled "school calendar". Great, you think, I'll add all of Little Johnny's football practices to the family calendar. You click the link, only to find out that it's a PDF, and if you want to add those items, you're going to have to retype each and every one of them. Not very customer-friendly, I'd say. If they had opted to provide the "active" link to an .ics file, you could select ech of the events and add them to your calendar where they'd be most useful.
Vendors are starting to get serious about 'shared calendars" and this is a small but important step - they need to provide ways for all of the organizations in our lives to easily give us these active calendar links.
Wednesday, January 18, 2006
Why subscribe??
If you've read my profile, you know I work with mainframes. In most cases (and in this one), it means the person involved has a lot of years under their belt. I happen to have worn many hats during that time period, one of which was supporting communications.
That experience leads me to question the current model of "subscribing" to things like calendars and RSS feeds. It's not subscribing in the e-mail / mailing-list sense, at all. Instead, it's what we used to call "polling". In polling, one device wakes up every so often, and sends a signal to the other to say "do you have something for me?". If the other end has something, it sends it, otherwise it replies basically "no, try later". The former is called productive polling, and the latter of course is non-productive polling. Non-productive polling is bad, because it uses network bandwidth to little effect. The trick, however, is to get the polling frequency "right" - too slow, and response time of the application is bad; too fast and you just increase the proportion of polling which is non-productive.
Non-productive polling is already happening with RSS feeds, with people setting their aggregators to check their favorite feeds too often. The underlying protocol is basically an HTTP version of "has there been an update?" (do you have anything for me?) and "not yet" (no, try later). It is multiplied by the fact that sometimes there are thousands of these aggregators asking per hour. There are also aggregators which are poorly implemented and which retrieve the latest feed over and over again even if it has NOT been implemented - which means they ignore the "efficiency" of "no, try later" and retrieve the entire piece of data again, over and over. One site owner, Glenn Fleishman, even studied some of these effects and wrote some code to deal with them that helped, but of course it didn't eliminate the source of the issue.
Calendar subscriptions, I fear, may in fact have the same problem, as people's calendaring tools keep checking to see if their favorite calendars have been updated. Given some people's desire to constantly be "up-to-date" they may set their tools to check even more frequently than they check RSS feeds, driving up the proportion of non-productive "polling".
Contrast this with a mailing list subscription. A mailing list uses bandwidth only when there's information to send. It of course requires a central mailing list service, which retains the addresses of the subscribers. There is some "polling" involved - your e-mail client checks regularly to see if "You've got mail!" which is a polling activity- but I don't think people generally set it to run so frequently.
Maybe we could combine the two to improve efficiency: when you subscribe to an RSS feed or calendar, it would send via e-mail some XML representing the new information, in a MIME segment with the proper Content-type, and e-mail clients would pass this to the local (desktop) aggregator or calendar client. This would work well in calendaring tools that already layer on top of e-mail, such as Notes and Outlook, wouldn't it?
That experience leads me to question the current model of "subscribing" to things like calendars and RSS feeds. It's not subscribing in the e-mail / mailing-list sense, at all. Instead, it's what we used to call "polling". In polling, one device wakes up every so often, and sends a signal to the other to say "do you have something for me?". If the other end has something, it sends it, otherwise it replies basically "no, try later". The former is called productive polling, and the latter of course is non-productive polling. Non-productive polling is bad, because it uses network bandwidth to little effect. The trick, however, is to get the polling frequency "right" - too slow, and response time of the application is bad; too fast and you just increase the proportion of polling which is non-productive.
Non-productive polling is already happening with RSS feeds, with people setting their aggregators to check their favorite feeds too often. The underlying protocol is basically an HTTP version of "has there been an update?" (do you have anything for me?) and "not yet" (no, try later). It is multiplied by the fact that sometimes there are thousands of these aggregators asking per hour. There are also aggregators which are poorly implemented and which retrieve the latest feed over and over again even if it has NOT been implemented - which means they ignore the "efficiency" of "no, try later" and retrieve the entire piece of data again, over and over. One site owner, Glenn Fleishman, even studied some of these effects and wrote some code to deal with them that helped, but of course it didn't eliminate the source of the issue.
Calendar subscriptions, I fear, may in fact have the same problem, as people's calendaring tools keep checking to see if their favorite calendars have been updated. Given some people's desire to constantly be "up-to-date" they may set their tools to check even more frequently than they check RSS feeds, driving up the proportion of non-productive "polling".
Contrast this with a mailing list subscription. A mailing list uses bandwidth only when there's information to send. It of course requires a central mailing list service, which retains the addresses of the subscribers. There is some "polling" involved - your e-mail client checks regularly to see if "You've got mail!" which is a polling activity- but I don't think people generally set it to run so frequently.
Maybe we could combine the two to improve efficiency: when you subscribe to an RSS feed or calendar, it would send via e-mail some XML representing the new information, in a MIME segment with the proper Content-type, and e-mail clients would pass this to the local (desktop) aggregator or calendar client. This would work well in calendaring tools that already layer on top of e-mail, such as Notes and Outlook, wouldn't it?
Outlook 12: is WebCalendaring an implementation of CalDAV, or something else?
I "hear" that Outlook 12 will have a "Sharing Server", and that among other things it supports a new function named "WebCalendaring".
Could it be that Microsoft is implementing CalDAV (a calendar-specific sharing protocol based on WebDAV)?
Or are they just providing compatibility with Apple's iCal calendar publishing and subscribing?
Could it be that Microsoft is implementing CalDAV (a calendar-specific sharing protocol based on WebDAV)?
Or are they just providing compatibility with Apple's iCal calendar publishing and subscribing?
Monday, January 16, 2006
The time has come to get back to posting!
I've really been remiss in keeping this up. I'm going to try to do better, and I'll start with some interesting news.
Hans Bjorhdahl, who refers to himself as "the calendar guy" for Micrsoft Outlook, says in some comments on his comics site Bug Bash that Microsoft Outlook will include a new, better UI, but also improved support for iCalendar. It looks as though Microsoft is getting serious about iCalendar interoperability, and practically nothing could be better for us as users of calendar products. Even if you don't use Outlook, you're sure (like I am) to need to interact with someone who does. Improvement of the situation can only benefit all of us. They still need to join the Calendaring & Scheduling Consortium, though.
Secondly, I just learned of the When 2.0 conference which was held in December, organized by Esther Dyson. Ms. Dyson (someone correct me and let me know if she prefers to be called something other than "Ms. Dyson") is a leading thinker whose opinions are highly respected in technological circles. When she and her group become interested in a topic, it can generate a lot of good "buzz", these kinds of things are generally very helpful at keeping momentum going, or starting something for that matter.
Even though we've been seeing a lot of progress in the calendaring field lately, I'd like to quote one phrase from the page linked to on that When 2.0 page:
That's the latest I have right now. I'm going to try to be more prolific in my posts going forward.
Hans Bjorhdahl, who refers to himself as "the calendar guy" for Micrsoft Outlook, says in some comments on his comics site Bug Bash that Microsoft Outlook will include a new, better UI, but also improved support for iCalendar. It looks as though Microsoft is getting serious about iCalendar interoperability, and practically nothing could be better for us as users of calendar products. Even if you don't use Outlook, you're sure (like I am) to need to interact with someone who does. Improvement of the situation can only benefit all of us. They still need to join the Calendaring & Scheduling Consortium, though.
Secondly, I just learned of the When 2.0 conference which was held in December, organized by Esther Dyson. Ms. Dyson (someone correct me and let me know if she prefers to be called something other than "Ms. Dyson") is a leading thinker whose opinions are highly respected in technological circles. When she and her group become interested in a topic, it can generate a lot of good "buzz", these kinds of things are generally very helpful at keeping momentum going, or starting something for that matter.
Even though we've been seeing a lot of progress in the calendaring field lately, I'd like to quote one phrase from the page linked to on that When 2.0 page:
With the growing use of cell-phones, GPS devices and local search, location has come to have meaning on the Net. But we still ignore time - even though computers already "understand" it far better than they do space.That's exactly right - we've let our calendar tools be "good enough" for far too long, adopting the attitude that as long as they work for us personally, we don't neeed to worry (yet) about making them work with others' calendars.
That's the latest I have right now. I'm going to try to be more prolific in my posts going forward.
Subscribe to:
Posts (Atom)