Bryan Stearns wrote:
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.
+1 - Bryan's solution is an excellent one to a frustrating problem.
It's not meant to be discoverable, its not meant to be accessible
(though it is, meta keys are perfectly accessible)
Heikki wrote:
- I think we should consider automatically discovering UI data problem
and resetting it (or just automatically resetting in case of an unknown
problem)
We're not in a state where we can detect what problems are UI related,
nor is the refresh-ui option even functional at the moment. I feel a
little bit like the argument for "discovering UI data problems and
resetting it" is like saying "we should detect crashes, and then not
crash just before we would have crashed" - sure maybe these are
possibilities down the road, (yes, even in the actual crashing case)
but its just not feasible to invest the resources towards the larger
more abstract problem of "UI related problems", especially when Bryan
has proposed (and mostly implemented...) such a focused, practical
solution for the near term.
Alec
...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
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
