On Wed, 23 Aug 2006, Jared Rhine wrote:
Let's say a hard-core server crash of osaf.us happens, and the most recent
backups we have are from 3 days ago (more realistically, I'm shooting for
backups every 4-12 hours) You, as a Chandler user, have had a busy week and
made a lot of changes in the last 3 days.
Would you want your server-side data to jump back 3 days in time? What do
you think Chandler 0.7a4 will do? Will all the local changes in Chandler be
preserved?
Or will the "server win" and all your data on the next
background sync gets changed to whatever's on the server?
I sure would hope so. It would be a shame if chandler lost local, more
accurate, data due to the re-syncing of old, out of date, data.
It's amusing to think that maybe server-side backups are not a "must have"
(except for at least account/username/password data) for Chandler user. If
osaf.us does lose all its data, maybe it's better to have people republish?
As long as the server can handle the load of all users re-publishing all their
data, more or less at the same time, when the server is back up ...
+ Do the Chandler desktop devs affirm that server-side backups are still a
good thing to have for osaf.us? That is, would you even want your data
restored after a server-side crash or would you rather republish yourself?
If a server is keeping data persistently, the least disruptive route for a
service would be to make disruptions unnoticed. Having Chandler re-publish all
collections in the background could be close, assuming bandwidth and load are
not a constraint. Still, having backups seems a safer route, no ?
+ If we *do* want server-side backups for osaf.us, what's necessary, if
anything, to make Chandler behave as well as possible in the event
server-side data jumps back in time?
We should make sure that Chandler doesn't re-fetch obsolete data.
Now, with a service costing $, how about having a server that doesn't ever
lose any data ? with replication and whatever else is required from a such
a persistent data server to be reliable ?
+ If we include server-side backups, can we add "jump back in time" testing
to the ecosystem test plans (if time permits)?
Time is such a fuzzy thing that this would not work. On the other hand, if the
server keeps version numbers then that may work. Chandler could simply not
re-fetch obsolete data and re-publish its newer version of a collection.
The user with the newest collection from a server version number perspective
would win the re-publish contest.
Still, I'm wondering why data retention expectations are being set so low. If
my bank can have a server that doesn't lose my account data then why can't we
do the same ?
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
