289
edits
Calendar:Architecture: Difference between revisions
Jump to navigation
Jump to search
→Comments are welcome
(major rework, part2) |
|||
| Line 155: | Line 155: | ||
== Comments are welcome == | == Comments are welcome == | ||
As this is just a proposal for an architectural shift of the calendar core, it is open for discussion. Feel free to comment on this. | As this is just a proposal for an architectural shift of the calendar core, it is open for discussion. Feel free to comment on this. | ||
=== jminta's first-glance comments === | |||
Let me begin by saying that I don't believe any of the issues I'm going to comment on are unsolvable, but for the most part, they merely reflect areas that I am unclear on after a first reading of this proposal. Clarification on proposed solutions to these issues would be helpful, in my mind. | |||
* My biggest concern is that there are certain instances where transaction information is not meaningful without having knowledge of the original object. The current implementation avoids the problem by giving listeners both the original and new objects, which they can compare in any way they see fit. Consider the following (somewhat artificial) scenario: | |||
** A user is currently viewing today in the Day View. Via the agenda-tree, unifinder, or some other method, the user edits an event currently schedule for 4pm-5pm tomorrow. He modifies the event to begin at 4pm '''yesterday'''. Now we have a transaction that contains only a new startDate. The Day View, upon receiving this transaction, has no way of knowing whether or not such changes affect it, because it has no knowledge of the original event, and hence, no knowledge of the start time. | |||
** A more concrete example might be the alarmService, which only cares about changes to objects with alarm information. If a user changes the start-time, the service will need to retrieve the object to learn if it had an alarm on it, and then determine whether that alarm is affected by the change. | |||
* The variety of transactions that can take place is extremely broad, and it is not clear that all such changes can be easily represented. Some types of changes the may prove difficult to embody in a transaction: | |||
** deleteProperty("X-PROP1") | |||
** changing an event into a task - would the transaction implement calIToDo or calIEvent? This requires that certain code areas that only care about one of these still need to watch other transactions. | |||
** changing the calendar of an item - could be handled with add+delete, but really, only the item's .calendar property is changing, which makes it seem like a commitTransaction() would work. | |||
** adding an attendee - If a transaction contains a single attendee, how can a listener determine whether this is a modifcation of a previous attendee or an addition of a new one? | |||
* I'm not entirely clear how this new model would change (if at all) our current occurrences model. As I understand the proposal, if I want to modify a single occurrence, I would ask for a transaction ticket on that occurrence. Committing that transaction would require the item's calendar to properly update the parentItem so it contains a proper set of occurrences. | |||
** Problematic(?) case: 'Modifications of all future occurrences' has recieved some attention lately. If I want to perform this type of change, it seems I would need a ticket from the parentItem? The semantics seem rather vague here regarding from whom I should ask for the ticket. | |||
* It is my opinion that the second cloning in modifyItem is a bug that we can probably fix by enforcing that only mutable items be passed in to modifyItem. (I don't think anyone ever even tries to pass an an immutable one.) In that case, we have the same issue in both models, one XPCOM object is required to be created for each change. | |||
* The listener's currently passed in for making modifications, at least in theory, ought to be told when errors occur and what kind of error it was. This is advantageous, in my opinion, and if this new model were to be adopted, I would like to see commitTransaction accept a listener argument as well. | |||
* This model puts a lot of stress on the event-dialog. It seems to need to figure out exactly what changed, rather than being able to simply rebuild the object from scratch and re-submit it. | |||
* This model needs to be '''absolutely certain''' that it has iron-clad enforcement of the rule that it's impossible to change an item other than by a transaction. Otherwise, I'm very scared of how easily a novice extension writer could completely break this model by following the intuitive idea of coding <code>item.title = "new title"</code>. | |||
* Finally, <code>calITransaction</code> will run into problems in truly implementing <code>calIItemBase</code>. Certain properties of <code>calIItemBase</code> depend on certain other properties being present. In the atomic model, this is not assured. The most critical example of this is <code>icalString</code>. Currently, the ics provider can be certain that it has all the information about an event if it calls icalString. However, calling icalString on a transaction will likely throw an error. Providers will need to be very smart in order to assure that they have all of the changes truly included in a transaction. | |||
==== Big Picture ==== | |||
To me, the main difference seems to be able to be summarized in the following table. If this is an incomplete or unfair representation of either model, please let me know. | |||
{| | |||
| Modifying item || cloned object || calITransaction | |||
|- | |||
| Modified object contains all item properties? || Yes || No | |||
|- | |||
| Disadvantage || Stale references are possible || Difficult to ensure that all changes have been extracted from transaction | |||
|- | |||
| Method of listener to solve disadvantage || Enumerate occurrences || Enumerate properties | |||
|} | |||
In short, both methods involve some type of enumeration. What we need to examine, in my mind, is which enumeration is easier from a coding/performance perspective. | |||
I'd like to thank everyone who worked on this model. There are some good ideas here, and regardless of whether this model is adopted or not, I think discussion of the proposals here will signifcantly benefit calendar development. | |||