Heikki brings up some good points, but I'm purposely keeping the focus
of this dialog narrow: It's there to make it easier for users who've
encountered a problem with Chandler today, and need to send us their
state for further diagnosis and/or to try a couple of things to be able
to resume working with Chandler.
It's not supposed to be a be-all-end-all of crash recovery mechanisms,
and I don't think we should bother reorganizing the startup code to
support retrying after a failure (at least, not right now - further
improvements could be designed and prioritized like anything else we
do). There's clearly more that could be done at startup, but that's
beyond the intent of my proposal.
...Bryan
Heikki Toivonen wrote:
Andi Vajda wrote:
I recently had a similar debate with Heikki about this. While having a
goal of no repository failures or chandler bugs in general is a laudable
one, preventing one from recovering from a failure when it happens is
shooting oneself in the foot.
We discussed the need of shipping command line db utility executables by
default. Ok for now, but not in the long run.
I sure don't want anyone to complain that Chandler sucks hugely because
we removed all the recovery facilities just because "they should never
be needed".
You are ignoring the rest of what we discussed. We should have Chandler
automatically recover everything that can be automatically recovered.
And for the cases where user needs to make a decision, put up some
helpful startup dialog along the lines Bryan suggested below. Further, a
situation where a user interaction is required should be extremely rare.
Finally, we shouldn't ship utility/functionality in the default
installers that, say, one in a million would find useful. It is
perfectly ok to create some optional power user utilities and have them
as separate downloads. And I said if nothing else, I'll do those myself
by hand if needed.
On Mon, 15 May 2006, Bryan Stearns wrote:
I propose we add a mechanism to put up a dialog on startup if the user
is holding down a metakey (to be named later; we can figure one out
that works on all platforms and doesn't interfere with basic
application launching); this dialog would offer this radio-group of
choices;
I agree this dialog would be useful. However, I disagree with the
metakey for a few reasons:
- it is not discoverable
- it might be a problem with accessibility, but I don't really know for sure
- I think we should consider automatically discovering UI data problem
and resetting it (or just automatically resetting in case of an unknown
problem)
I propose that we just put up the dialog automatically when we
encountered problems during startup.
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
