[
Lists Home |
Date Index |
Thread Index
]
That's mostly it. Then it is an issue of survival in
an event-driven environment, that is, does the system
AND your understanding of the environment in which it
operates evolve fast enough? Urgency must be harnessed
to quality and which you emphasize is determined by
the criticality to the system of an event type from
within the system or from the environment.
Notification should not initiate under-evaluated or boilerplate
responses. That is not the way. Selection of the correct
response is the behavior that must become instinctive, not
the response.
So to answer the original query about identity constraints:
it depends. Don't do it just because you can. Do it because
you must. How do you know? That's the job and why they
pay you the big bucks.
We don't bet our badges on our mistakes. We all make mistakes.
We bet our badges on the failure to act.
len
From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
If I'm following you here (and I'm not sure that I am), I think the
normal attack is recursive boot-strapping: start with open security/no
audit/no validation, inject the fundamental constraints. Now add the
base security, make the base constraints required, validate the base
against the base, point the audit data at the results of the validation,
etc. (Possibly at this point you add in database constraints that didn't
previously exist, turn certain fields non-null, etc.) Now you can inject
the next layer and go around again. For our system, if we were starting
from scratch we'd have to fake the creation of 2, maybe 3 layers before
we'd have the complete bootstrap in place. Is it provable? Not in our
case, but I can't see why it couldn't be in theory...
|
