Confirmed users
3,816
edits
Calendar:Hamburg F2F Meeting: Difference between revisions
Jump to navigation
Jump to search
→Meeting Notes and Decisions
| Line 214: | Line 214: | ||
* 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 [http://developer.mozilla.org/en/docs/Mochitest_FAQ 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. | * 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 [http://developer.mozilla.org/en/docs/Mochitest_FAQ 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. | * 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 one of the release engineers at Sun. TODO: Someone should edit this with his name--I didn't understand how to spell it. | |||
* 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. | |||
==== 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. | |||