Calendar:Hamburg F2F Meeting
From MozillaWiki
Information regarding the 2. Mozilla Calendar Developers Face-to-Face Meeting
Americans should read 20 things to keep in mind when visiting Germany first :-)
Contents
Who
| Tentative Attendees | |
|
|
Where
Meeting:
Sun Microsystems GmbH
Nagelsweg 55
20097 Hamburg
Germany
Lodging:
Junges Hotel
- Approx. 70,- € with Sun Discount, near by Sun's Office
Between 100 € - 130 €
- Hanse Clipper Haus Boardinghouse nice location
- Wedina nice location
- SAS Radisson (Favorite, good public transportation)
- Dorint Novotel Hamburg Alster
Public Transportation
Airport -> SAS Radission
- At the Airport take the Bus with the number 110
- Get out at the Station called Ohlsdorf
- Transfer to the Subway
- Take the S11 (direction: Blankenese)
- Get out at Dammtor (Messe/CCH)
SAS Radission -> Sun
- At Dammtor (Messe/CCH) take the S31 (direction: Harburg Rathaus)
- Get out at Hammerbrook (City Süd)
- this is a 6 Minutes ride.
.
When
| From: | Saturday | 2007-04-21 | 10:00AM |
| To: | Tuesday | 2007-04-24 | 3:00PM |
Agenda
Day 1 (Saturday)
| Time | Topic | Description |
| 10:00-12:30 | Brunch | Meet-and-greet |
| 1:00-1:30 | Welcome | (Daniel) Agenda overview, goals |
| 1:30-2:15 | User Feedback | (chris-j) |
| 2:30-4:00 | Product and Release Strategy | done by sipaq What is our current situation (strengths, weaknesses)? Where do we go from here (Integration into TB/SM? Two product strategy?)? How can we do our releases better. |
| 4:15-5:30 | Sunbird and Lightning | (chris-j) discussion on designing features for both Apps |
Day 2 (Sunday)
| Time | Topic | Description |
| 10:00-10:45 | Feature Discussion Shorts* | Off-line Mode (Daniel) |
| 11:00-11:45 | Feature Discussion Shorts* | Searching Calendars (ctalbert) |
| 12:00-12:30 | Project Ownership | (All) |
| 12:30-3:30 | Lunch | |
| 4:00-4:45 | Feature Discussion Shorts* | Pluggable Provider Packaging (Matt, Daniel, Philipp?) |
| 5:00-6:00 | Milestone& Roadmap Planning, Wrap-Up |
Day 3 (Monday)
| Time | Topic | Description |
| 10:00-12:00 | Milestone& Roadmap Planning Continued, Cont. | |
| 12:00-1:00 | Lunch | |
| 1:15-1:45 | Test Strategies | align forces, prevent regression (ulf) |
| 2:00-3:00 | Automated GUI Testing | (Thorsten Z.) |
| 3:15-3:45 | Thunderbird Integration | (chris-j) |
| 4:00-4:45 | Feature Discussion Shorts* | Group scheduling (ctalbert, Daniel) |
| 5:00-6:00 | Automated Builds & Tinderbox | (Ause, Matt) |
Day 4 (Tuesday)
| Time | Topic | Description |
| 10:00-12:00 | QA-Track Shorts* |
(ctalbert)
|
| 12:15-1:30 | Lunch | |
| 1:30-2:30 | Feature Discussion Shorts* | Time zones (ctalbert) |
| 3:00 | End |
Note on "Shorts": These are intended to be 45min segments on a particular topic/idea. They can be demos/prototypes, architecture problems/ideas, short talks, or really almost anything. Ideally, they should be split 15min for the presenter and 30min for discussion, but this is flexible. If you wish to present here, please sign up for an open slot. More slots can be created if the need arises.
Meeting Notes and Decisions
Day 1 Saturday
- We need to focus on our testing on Lightning and because many of our new features are landing there (iTIP WCAP etc). So need to make testing easier on Lightning possibly by having an RDF to autoscript a dummy mail account so that it will be easier to install Thunderbird and run lightning without worrying about your private data.
- Philipp (xFallenAngel) has scripts to help ensure that patches have the proper style and there are no "compile" typo errors in your javascript.
- Need to talk to David B and M Scott to find out if we can make a "Thunderbird now with Calendaring" sort of idea and incorporate calendar by default into Tbird.
- Decided that there will be a tasks view because you cannot properly display tasks in the calendar view because tasks may not always have dates and will not easily be displayable. Specifically this means:
- Integrate Lightning into Thunderbird with the "today button" in toolbar. Also add set of three buttons in lower left to switch to different modes for the application: the modes are Mail, Calendar and Tasks.
- Clicking on "today button" toggles on a today column that shows you a summary of the current events and possibly another small window displaying tasks (todo: define how to decide which tasks to display). This also allows you to create simple events and tasks
- Clicking on tasks button will show a new task view with all task details available. A sort of "spreadsheet" format.
- Clicking calendar view does not show mail folders and shows essentially like the mockups that Christian has proposed.
- There will be noo merge of tasks into the calendar views at all (or that may be a preference, but this is done to remove the dependency on the spurious nature of dates inside of tasks).
Day 2 Sunday
- Discussed with mvl and the team and came to the conclusion that the project "head" should be a person that is working on the project full time. We decided that Daniel is the best person for this. Additionally, Clint will be starting at Mozilla next week (primarily working on Firefox). Daniel and Clint will work together to ensure that the project maintains a link to Mozilla and the Mozilla community.
- We will support "Lightning in Sea Monkey" but only if we can do this simply without #ifdef'ing the code in some kind of terrible way.
- Discussed offline issues with mvl. Decided several items about the offline support
- We will start out by better optimizing the recurrence lookups in the storage calendar so that storage calendar can be used as a caching mechanism.
- This will be useful in conjunction with the change-log mechanism that mvl and antonio are working on.
- offline support will also need synchronization interfaces that will encapsulate the conflict handling and will launch any conflict handling UIs that we create.
- There was some discussion on how to get changes down between the cache and the server. We believe that this can be done with etags on CalDav and WebDav. it is done via a specific server call on WCAP and a specific XML command in GData. For flat-file ICS, we are not exactly sure how this would work.
- We decided that we want to support searching for other people's calendars on the same calendar "server" type. That means we'd want to support the ability to find other WCAP or Google or Caldav users. This of course will depend on server capabilities.
- Discussed using a calISearchable interface that providers that have this capability will implement.
- Philipp gave us an update on the GData extension for Google Calendar
- Alarms will be in soon
- Attendees will be in soon - the responses and invitations are sent and processed by google. Changes to the events will come down during normal refresh events.
- Recurrence - Cannot complete this patch because of the way that the provider interface handles the deletions of occurrences. WCAP has the same problem. Essentially, removing a recurrence is seen as a "modify" by the provider. This breaks undo/redo capability because you actually performed a "delete" as far as the server is concerned. So, to undo you have to remember to tell the server to "add" the occurrence back in. Need to work out a fix to this, possibly changing the provider interface to handle this.
- Comments - Guests (attendees of an event) can leave a comment on an event. It might or might not be useful to reflect these in events. But, there is no mirror for these comments in RFC 2445. One option would be to have the GData provider create an attachment from these comments. This is low priority
- Optimistic Concurrency - Ensure that two users do not change the same event. We need to throw a conflict message if we detect that this has happened. WCAP has the same issue, and simply overwrites what is on the server in this case. This is another item that would be handled by synchronization interfaces that were mentioned w.r.t. the offline support.
- Subscription - Philipp has proposed a subscription dialog to allow users to easily any of the Calendars that already exist in the GC UI. This is similar to the WCAP Subscription dialog. The only way to find other people's Google calendars that are not already in the UI is to hack the UI to enter someone's google email address (There is no API equivalent). The target user must accept this request.
- Group Scheduling - Google has a way to get a FreeBusy feed, and this could be used to populate the new prototype event dialog event F/B information.
- Providers must have a mechanism to publish their capabilities - perhaps as some kind of flag that can be checked by items like the event dialog. This would enable items to be removed based on what the provider cannot support. This capabilities querying feature will become more and more important as we expand our provider offerings.
- We began product roadmap discussions. We decided that we want a 1.0 as soon as possible that makes sense from a feature standpoint. Our philosophy here was that we wanted to only take changes that create a workable basic set of functionality that will be rich enough for end users to use, as well as being rich enough for people to create good extensions from.
- An example here is the support for SMS alarms. We decided it was a "nice to have" (NTH) because that support can be easily added either by users (sending SMS email to themselves) or by extension writers once we have the ability to send an email alarm. Therefore, the feature for email alarms will block, but SMS will not block the release. We applied this type of logic to everything.
Day 3 Monday
- Continued and completed the provider discussion. You can download a spreadsheet of it here. We will also update the wiki roadmap in the future.
- Discussed Test automation with the test automation guru at Sun. Unfortunately the test automation for Star Office will not port into the Mozilla stack. So, we decided to investigate the MochiTest to see if this can be used from within calendar in the same way that it is used in Firefox. Clint and Ulf will take this on. Others are of course welcome to help out in this effort.
- We also decided that until the new UI lands, we should begin writing API tests that use XPCShell (bug 365212). This will be re-discussed tomorrow at the morning quick QA Session. We unfortunately could not invite others to this because of time-constraints of Thornsten, the Sun QA automation guru.
- Matt outlined the build-system, release process, and Tinderbox setup process to ause, one of the release engineers at Sun.
- We also talked at great length about how to perform invitations in the new UI that we decided on to better integrate Lightning into Thunderbird. We decided that there will be an invitation management UI that will be part of the "calendar" mode. We will indicate the number of invitations (both email and server based invitations) by bumping a number next to the "calendar mode" icon. (This is similiar to the way that a number for new emails are shown as an icon next to the thunderbird icon). Once you click the calendar mode button the calendar view shows up wnad you have an invitation dialog available. YOu will be able to accept/tentatively accept/decline the invitations from this UI. You will also be able to drag the invitations from this UI into some other calendar (which generates an "Accept"). If you double click on a invitation from this UI you will see the invitation displayed in a "read only" version of the event dialog. Default behavior will be to accept, and as far as sending notifications back, it will default to bring up the compose window to allow the user to edit the response.
- We also discovered that by using a Filter, you can filter messages based on the "Content-Type" setting, and if you do that, it seems that the filtering code pre-screens the message in order to determine information about the attachments. This means that we might be able to do the same thing in order to "under the covers" load emailed invitations into the invitation management system.
- Philipp will have a friend of his look at our QA Wiki page and either reorganize it for us- and/or tell me where it needs to be improved.
Day 4 Tuesday
- Provider Packaging
- WCAP would most likely be pre-configured by administrators in the "real world".
- The other providers: Google webDav, iCALENDAR, and CalDav need clarification on what the user is actually trying to create. We noted that many people get confused between the "iCalendar" and "CalDav" option. Need to make that more explanatory.
- Decided to get rid of the first page that asks "on my computer" or "remote". Instead, we will add a "Local Calendar" to the list of providers and make the provider list the first page.
- Noted that most users cannot understand all the various differences between "Subscription" and "Create" because to a user it all appears to do the same thing: Add a calendar to my calendar list.
- Change "Subscribe to a Calendar" to "Add a Calendar"
- Change "Create a Calendar" to "Add a Calendar"
- As a person clicks on a provider, if the location (URL) field is needed a sample URL field will display so that the user has more of an idea as to what to put in that field. This is the same thing we currently do for attendees in the current event dialog.
- We will auto-create radio buttons for installed providers, but if there are more than 5 providers, then we will create a drop-down list instead so that the UI is not cluttered
- There will be a button on the provider page that will link to a "providers" page on our www site. We chose NOT to link to add-ons because if anything were to change w.r.t. add-on links, or if providers were not up there, we'd have to recompile the application to deal with that. But, if we point to a provider specific page on our own www site, that gives us far more control. In an ideal world that www site would be a simple re-direct for add-ons. It would be really great if we could figure out a way to install our providers from the web so that when you click on a download link the XPI doesn't try to install itself into Fx (of course, other non-Fx add-ons have the same issue).
- A provider will have the ability to show/collapse the location field and the ability to add more pages between the provider selection and the finish page of the "add calendar wizard".
- We should have an ICS File browser for the ICS provider type (might be post 1.0)
- We should have the ability to create a calendar for the calendar user on some well-known calendar servers (icalShare, Cosmo CalDav, etc). That's definitely Post 1.0.
- Need a way to specify that various providers depend on either Sunbird OR Thunderbird + Lightning. Currently, you can only specify Sunbird OR Thunderbird versions using em:REQUIRES tags in install.rdf. There is no way to also specify the Lightning version that you require (because this would require Lightning to also be present on Sunbird). This is a known bug, and there may be some ways to hack around this by invisibly including a Lightning extension inside Sunbird (it would not be displayed to the user). That hack might be necessary since the fix for this will probably NOT make Thunderbird 2.0.
- Need better error handling for when providers fail to add calendars, and for when the dialog is given invalid information.
- Providers also need a progress channel so that they can update the UI as they work on creating a calendar. This would also be useful during time consuming updates/changes.
- Christian will draw up some mockups for new "Add Calendar" UI wizard.
- We also met with the Sun Project Manager that manages the Sun effort on this project. He would like us to be able to have more of a "nailed-down" set of features per release so that he can generate internal "buzz" about our next point releases. I think that he and Simon could possibly work together as those releases get closer to do this.
- Timezones
- We looked at a new UI Mockup for a clickable, graphical timezone picker that will be replacing the one in the prototype event dialog and will be replacing that hideous drop-down in preferences.
- From there, we launched into an incredible discussion on foreign timezones and provider specific timezones (not all providers will support the full set of Olsen timezones).
- We talked at great length about centralizing the timezone mapping code, and then about not centralizing the timezone mapping code. We also talked about simply fixing the issues in the storage provider, and then about how we would upgrade timezones in that case. This is a section that is confusing enough to need its own subsection. Grab yourself some juice.
NOTE: The "Issues" section and some of the "Possible solutions" section were items discussed at the meeting. The items beyond those sections are some of my (ctalbert) own ideas that occurred to me while writing this down. I left them in here for now since it makes a coherent whole. If these ideas have any merit, I'll pull them out of here and add them to my timezone feature page.
Timezone Discussion
Issues
- Timezones are POLITICAL. They have as much to do with geography as the political body that invented them has to do with geography. They can and will be changed at whims.
- Timezones have the appearance of being geographical constraints because their standard UTC offset is usually calculated based on the number of zones between the zone in question and the prime meridian timezone (UTC). However, there is nothing that says this MUST be the case.
- If two timezones have the same standard UTC offset, but DIFFERENT DST definitions, then those are different timezones
- If two timezones have the same standard UTC offset, but one defines a DST setting and the other does not, then those timezones are NEVER equal.
- One possible exception/optimization regarding timezone equivalence: If two timezones have the same standard UTC offset, different DST definitions in some cases but the same DST definition for the time period that a specific event exists, then those could be considered to be equivalent timezones (only as far as the specific event is concerned).
- Even in the best cases, different server providers will use different versions of the Olsen database (Cosmo CalDav) and in the other cases, the server providers will use only a subset of Olsen (WCAP), or they will use something altogether different (GData and CDO (Microsoft Exchange)).
- READING: We want to be able to map the provider timezone to our internal Olsen database in order to properly display the event.
- WRITING: When writing an event back to the provider we want to map the timezone back into the provider specific timezone. We do not want to overwrite the provider timezone with a Mozilla timezone when we update the item.
- The current local cache does not store provider specific or "foreign" timezones. These are never persisted in the current application, and this has massive implications for any type of offline mode that uses the storage provider as its cache engine.
Possible Solutions
- One solution is ensure that every timezone is stored for every event. This would mean that we would duplicate quite a bit of data unless we were able to ensure that every item on the timezone were identical between two events. But, since making every service provider use the exact same timezone database as Mozilla is not a viable goal, this optimization will not help greatly. Instead, we would have to store every timezone that an event uses on a given provider. This could be stored inside the provider's storage mechanism -- it need not be pre-populated before hand. For example, we can merely cache the provider timezones as we encounter them, which is what we do now.
- Furthermore, we need to change the storage provider so that it will store timezones for various events so that when "foreign" timezones are encountered (as in iTIP/iMIP or import/export) those timezones are persisted.
- For Offline, we may be able to handle this by storing both the provider timezone and the corresponding Mozilla timezone.
- We need to investigate whether or not it would be viable for us to provide a centralized interface to perform mapping from provider timezone to Mozilla timezone. It might be something that the provider code itself may be better positioned to handle, but I would hate to force every provider author to perform this mapping if it could be easily generalized and handled.
- However, mapping from Mozilla Timezone to Provider timezone would have to be done via the provider since we cannot have the internal calendar interfaces keep track of all the possible provider timezones. This might be optimized by always storing the provider timezone in a database (as I mention above for the case of offline mode) so that in order to map from Mozilla Zone to Provider Timezone for a given event, you could simply look up the original provider zone in the database.
- Of course, providers that do not use a database would be at a disadvantage with this approach and would have to map from Mozilla to Provider zone by hand. That is unless there were a generic interface for this, which would be some version of the Timezone Database Service.
Timezone Database Service
- The timezone database service would be a server-side service that would handle timezones for provider servers. It is not implemented yet, but its specification has been submitted to CalConnect (and possibly IETF). It's next step is that it needs a reference implementation. Since we cannot predict when this support will be available, it does not make a ton of sense to put support for the timezone database service into the 1.0 calendar release, unless that support can be added as an extension.
- If the support were added as an extension, then the handling of mozilla timezones could be funneled through that database and future timezone upgrades might be made easier by simply having AMO update the extension. However, it remains to be seen how easy/difficult it would be to be able to substitute a critical piece of infrastructure with an extension.
- If we decide to provide a one-way Provider Timezone to Mozilla Timezone mapping interface, then that interface should store both the provider timezone definition and the Mozilla timezone definition. This way it can easily perform backwards mapping at the request of the provider. This storage system could easily be imagined to be the first step toward a timezone database service.
Timezone Upgrades
- A timezone has been upgraded if its RRULE or RDATE definitions have been updated more recent information. For instance, if you had last year's timezone definition for the United States, you would have an RRULE valid from 2006 into the future, and with this year's definition, it would exactly the same except that it would have an RRULE valid for 2007 into the future. You can use this rule to detect upgrades to timezones, and as such could apply some kind of upgrade logic to update events using the old timezones.
- CAVEAT: In order to generate timezones readable to versions of Outlook prior to Outlook 2007, most providers and clients only use one current RRULE in their timezone definitions. In this case, you have no prior indication that this timezone ever existed, and you cannot merely use the TZID to identify older versions of this zone. In this case, you have to add this new zone to your database and cannot update any of the older events using a "possibly" older version of the timezone.
- Solution to the above CAVEAT: If a provider were informed when it received a new set of timezone definitions, then it could update the shared timezone cache by updating all of it's old timezone definitions for the events it owns. This would mean that the timezone cache should also store the provider's version so that the provider can avoid updating timezones from other providers that might happen to have the same TZID.
- We may want to investigate the possibility of cleaning out a shared timezone database when events are removed. But, if this is to succeed then the timezone database must be informed when on all event deletions and modifications so that it can adjust its accounting of whether or not a specific timezone is still being referenced by a given event.
- By storing the provider's timezone version (a value that is changed when the provider's timezone definitions change), and by always storing the provider timezone definition we may be able to mitigate the timezone destruction caused by having two versions of Calendar access the same ICS file.
Possible Items to store in a central timezone mapping database, or in the storage provider so that it can be used as an offline storage cache for providers
- Provider UID ( this would include UID for Mozilla providers i.e. local storage etc)
- Provider timezone version
- Calendar UID
- Event UID
- Provider Tzid value
- Provider zone definition
- Mozilla Tzid value
- Mozilla zone definition
Resulting Bugs
These bugs were either filed as a result of the meeting or were spoken of during the meeting.
TODO: File them, add them.
- bug 373330 (Can't Browse Sunbird Addons}
- bug 327783 (Offer more ways to switch between mail/calendar views)
- bug 379005 (Create Stub Extension that allows <em:requires> tags in Sunbird/Lightning Extensions)
- bug 378872 (Make providers easily pluggable)
- bug 306692 (Simplify file menu (New calendar vs. Subscribe to calendar))
- bug 314594 (No error message if invalid URL used for new calendar, creates invalid calendars)
- bug 379029 (Add provider capabilities to calICalendarProvider interface)
- bug 365212 (Use xpcshell based unit test framework)
- bug 313822 (Make lightning work on SeaMonkey)
- bug 366923 (implement changelog-based offline support)
- bug 196942 (Ability to replicate server events to local for offline viewing)
- bug 360799 ([RFE] Lightning - Email Alerts)
- bug 379200 (Thunderbird should show an invitation icon next to the messages that contain invitations)
- bug 378270 (Remove 'Rotate' button and move the rotate option to the views menu)
A list of these bugs as a bugzilla search can be found here
Roadmap Bugs have been moved to Roadmap Page.
