WBMM> WBMM requirements

WBMM> WBMM requirements

ElliottBradshaw at oaktech.com ElliottBradshaw at oaktech.com
Fri Feb 7 14:56:22 EST 2003


I got around to subscribing, and I read the history.  (Bill, how many
people have joined?  It might be worth a reminder announcement to prod
people who, like me, are interested but haven't got around to it.)

Bill, when I try to read the posted charter I get a complaint from Acrobat
about a missing or corrupted encoding (CMap).  Does anyone else have this?

Writing requirements is hard...one man's requirement is another's design.
Based on Bill's original notes, there seem to be end-user use-cases covered
by the "requirements" section and more internal, technology needs covered
in the "objectives" section.  This seems to me like a good division.  Using
this approach, the discussion of SNMP seems to be mostly in the latter
category.

One reason why some of us gravitate toward thinking about SNMP is that
there is so much overlap in the nature of the technical problem to be
solved (encoding, transport, who-calls-whom), and in the end it would be
very useful to limit the number of schemes that a device needs to support.

Could SNMP be extended to cover the use cases Bill mentions?  In some
cases, yes, but the firewall is a big problem.  Most of the technical
challenges for connecting clients, servers, services, and devices seem to
me to be parallel to what PSI has already worked through.  Could PSI be
extended to handle WBMM use cases?  My guess is that it could.

Before we jump into the transport-layer issues for WBMM I'd be intersted in
understanding the use cases better...specifically who calls whom when, and
when do we need intermediate servers.  Some sort of message-passing
pseudocode might be worthwhile for the key scenarios.  If there is interest
in the group I'll help work this out.

I'm not as convinced as Bill is that there is a black-and-white division
between what internal IT people want (traditionally users of SNMP) vs. what
external service companies would want (target of WBMM).  Specifically, it
may be that different vendors will want to draw this line differently.  So
again it could be useful to have one infrastructure that can be applied to
both of these situations.

I think we should understand the WBMM use cases in more detail.  As a
parallel (and probably separate) effort we should work out a long-term
roadmap that would let SNMP be replaced by one or more XML-based protocols,
perhaps with PSI as a framework.  Hopefully these will converge at some
point, but we don't really know yet.

  E.



------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534





More information about the Wims mailing list