Confirmed users
503
edits
Calendar:Architecture: Difference between revisions
Jump to navigation
Jump to search
→comments from mvl
| Line 196: | Line 196: | ||
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. | 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. | ||
=== | === comments from mvl === | ||
There are some good points in the article above, and I agree that changes might be a good thing. Hoiwever, what worries me, is that the changes are deep in the backend. I fear that implementing them in one big (crash) landing mught leave our app(s) in an unusable state for maybe a few weeks. Doesn't sounds like a good idea this soon after the previous rewrites. | |||
So what I'm hoping that we can do, is making changes in small steps. We should try to always have a usable apps. There may be bugs, but they should be fixable in a relativly short time. That way, we can also test things in small parts. | |||
Now, about the contents of the document. My understanding is that there are two basic problems: 1) working with occurences vs parentitems and 2) excessive cloning. | |||