Difference between revisions of "Changing the URL of a calendar"
| Line 1: | Line 1: | ||
| − | { | + | {Languages|Changing the URL of a calendar} |
| + | |||
The direct change of the URL of a calendar is a nontrivial operation. An Implementation | The direct change of the URL of a calendar is a nontrivial operation. An Implementation | ||
of this feature has to consider and handle all possibilities correctly. Ensuring data consistency | of this feature has to consider and handle all possibilities correctly. Ensuring data consistency | ||
Revision as of 11:09, 6 September 2013
{Languages|Changing the URL of a calendar}
The direct change of the URL of a calendar is a nontrivial operation. An Implementation of this feature has to consider and handle all possibilities correctly. Ensuring data consistency requires much work.
Let's take switching to SSL as a simple example, ie. one now connects via 'https://' instead of 'http://'. In an extreme case we might be dealing with a entirely different server.
Other users may want to explicity exchange the server with this function. In such a case the app would be required to associate the calendars on the new server which is difficult if the two lists differ completely.
Also imaginable is the case that both calendars aren't synchron. A duplication or a merge of the events can be just as bad as the complete loss of the data.
An analogy: Let's imagine our user is reading a book. Now we want to exchange the book for another while he's still reading. In the best case it's exactly the same book opened on the same page, having the same font, etc... However, even a small change requires an adjustment. If we're on the wrong page we need to turn it. If the edition differs we may need to search the spot where we stopped reading, maybe it's not there any longer. Or it's even a different book and you might have to re-read from the beginning. The number of possible problems is almost infinite.
The effort required to re-create the account is fairly low in comparison. If the user has to, against all odds, frequently change the URL then he may use a feature called "Auto Provisioning" ( http://dmfs.org/wiki/index.php?title=Auto-provisioning ). This Feature will be improved and extended further in the feature.
The option to change the URL of a calendar is however on your TODO list. It just has a low priority, especially since there is an alternative solution. Furthermore we want to ensure that implementation does not contain any errors. The security and integrity of the data has the highest priority.
