Thanks for your comments. I wish others would take the time and
do the same, or at least post a message to the list saying they
are in full agreement with the document's contents.
> 2. (Overview) Simple is stressed as an overriding characteristic of the
> requirements. I wonder if the current model, with it's publication and edition
> paradigm is really as simple as originally intended. This would be unfair as a
> criticism (and is not intended as such) since I do not have an alternative
> model to offer. It's just an observation that the current state of the
> architecture may not fit the icon of simplicity put forth in the requirements.
> Simple is a very hard thing to define and it may be better to avoid the term.
> Given that events really capture the essence of the situation perhaps the name
> should be changed to ES&NSE (Event Subscription & Notification Services
> Environment).
I can certainly understand how you might think the Publication/Edition model
is not very simple. I think the reason for this is that we have not yet
fully discussed the requirements as mapped to a proposed design/implementation.
Perhaps once we start looking at potential designs (including the existing
design as conceived by Underscore), then folks will be able to better judge
whether the Publication/Edition model is useful, or whether something else
should be pursued.
For the time being, though, let's leave the project name as it is (ie, Sense).
> 3. (SENSE Requirements) The primary motive... lack of good Trap registration
> and distribution in SNMP may well be handled in SNMPv3. This motivation should
> be re-investigated.
Yes, you and I have privately spoken about this situation. Sense, having pre-
dated SNMPv3 by quite some time, may now need to be reexamined to see if
SNMPv3 eclipses the need for Sense, or at least certain parts of it.
I need to do another head-to-head competitive analysis of SNMPv3 against Sense,
similar to what I had previously done for DMI v2.0. Hopefully I'll be able
to get to that in the next week or so. (By the way, can anyone give me some
quick net pointers to the SNMPv3 docs?)
> 4. (#14) Client ACK of event. I'm not sure this should be required in all
> cases. Perhaps 2 modes, an ACK or NotACK mode. This will help alleviate (#16) -
> server resource management. The server can really bloat while waiting for ACKs
> from clients who disappear etc. It is feasible to consider an "unreliable" mode
> of operation.
Excellent observation, Harry. We, too, have found that an "unreliable mode"
is certainly viable in certain environments. This shouldn't be too hard to
add to Sense. Do others have any comments on this addition?
Right off the top of my head, I'd say that the subscription request would be
defined to have one or more message properties indicating the level of reliability
for events delivered for that subscription.
The client API in the current implementation actually supports the kinds of
reliability controls you mention. However, these controls are used across the
client session and can not be altered on a per-subscription basis. Perhaps such
session-wide controls are enough for you, though.
> 5. (not addressed) The requirements do not appear to directly address the need
> for filtering. I know the requirements do not address data content and it could
> be argued this is where this topic belongs, but I think filters are significant
> to any event based scheme and should at least be mentioned. I also acknowledge
> that filtering is exactly one of the reasons the current SENSE architecture may
> appear somewhat less than simple (my comment 2, above).
Ah yes, filters. As I described in Boulder last week, filters, or more precisely,
filter specifications, are one of the primary reasons we conceived of the notion
of an "Edition". Filter specifications can get very, VERY ugly, and before you
know it, you often end up designing an entire "language" to deal with that.
This is something we at Underscore desparately wanted to avoid. I'll address
that issue in more detail in a later message. However, for now, suffice to
say that a requirement exists for a client to be able to specify receipt of only
a subset of all events that may be available from a given source. Exactly how
that "subset" is defined and handled is a topic for design and implementation,
IMHO.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------