|
Fred, do you really think that [If not, the developer makes a call
on which situation most accurately conveys the situation.] is possible
and will help interoperability in some way?
If two network devices report changes of properties of
their network connection configuration, one as ConnectSituation and another
device reports it as ConfigurationSituation because the rule indicated above was
in effect, is that helpful?
It is
much worse here than in your SQL example. Those in SQL are errors and I may not
necessarily care. In WSDM this is the situation that needs to be reported on
events that are not errors and that is many more events than just errors that
need to be classified. In many cases with SQL, the client would not care what
error there was and so this classification is for those who can deal with it.
Here, in WSDM it is for everything that happens one has to decide what class of
situation it falls into in order to let someone else know about what happened.
In the real world if one faces this, one may likely decice to be silent instead
of going through the decision process.
-- Igor
Sedukhin
..
(igor.sedukhin@ca.com)
-- (631)
342-4325
..
1 CA Plaza, Islandia, NY 11749
IMHO, this makes it worse.
I thought the idea was to provide a
broad indicator, not a complete list of everywhere it might be
appropriate.
As Tom indicated previously in this thread, if something
fits a couple of places, there are really probably two different events going
on, each of which has a situation. If not, the developer makes a call on
which situation most accurately conveys the situation.
These are always
gray areas, no matter what anyone does. The broad in broad
indicator says that its a gross measurement. Those interested in the
details are required to dig deeper. Those not so interested,
won't.
I don't see how this is any different than, for example, standard
SQL errors. To translate,
If the database has to abort a transaction because it could not
get enough disk space to extend the table, is that a resource error or a
transaction error? IMNSHO, that's a transaction error: that's
because the transaction is the effect closest to/with the most effect on the
user (they just got a bunch of work tossed). If it didn't abort the
transaction, but just returned it couldn't perform the, say, insert, it'd be a
resource error.
The value, though, is the same: The user
writing code [in our case, a manager, in the SQL case a db app developer]
doesn't care about the details unless they want to dive in and see more
stuff. But, if they've dived in and understood Oracle errors and then run
their app against Sybase, they get some nice portability until they dive into
the Sybase pool.
/fred
Sedukhin, Igor S wrote:
Ok, if we accept what you propose I may let
this go. It is not getting any better, it seems...
I
suggest that we decice this on the call tomorrow.
-- Igor
Sedukhin ..
(igor.sedukhin@ca.com)
-- (631) 342-4325 ..
1 CA Plaza, Islandia, NY 11749
Igor,
Do you think that allowing more than one situation
category would cover your examples better? If events are related to more
than one it can be expressed in the message...
William
#1 there is a
property which is mydevice:ConnectedTo which indicates the name of the network
which the device is currently connected to e.g. Nothing, GSM900, GSM1900, GSM
1800, 802.11g, 802.11.b etc. Such property is writeable and could be set by
the manager, so this is configuration. When a property change event has to be
generated by an manageability implementation for this device, what would be
the situation category to put in the event data: Configuration,
Connection or Report? What part of the WSDM spec will be sufficient to
describe the choice for an average developer?
#2 there is an
OperationalState property and an event is generated for this property change
when state transition from DOWN:CRASHED to DOWN:STOPPED. What does one put as
a situation category: Availability, Stop or Report? In this case,
availability did not change so it is just a report, but the operational state
certainly defines the availability. DOWN:STOPPED is a state which indicates
that resource is stopped, but its availability didn't really change in case of
this transition. However this would not be true if transitioning from UP to
DOWN:STOPPED, in that case the availability changes. A) What in the spec
would lead one to be crystal clear on which situation category to pick in this
case? B) What if the event generator has no knowwledge of the actual resource
state model? How would it decide between UP->DOWN:STOPPED and
DOWN:CRASHED->DOWN:STOPPED?
-- Igor
Sedukhin ..
(igor.sedukhin@ca.com)
-- (631) 342-4325 ..
1 CA Plaza, Islandia, NY 11749
|