Subject: SENSE> Where to go from here?

From: Jay Martin <[email-masked]>
Date: Sun, 02 Nov 1997 11:08:36 -0500

Suffice to say, the Boulder meeting didn't go as well as I expected.
A private conversation with Dave Kellerman (Northlake Software)
provided critical insight into the nature of the problem.

Underscore has spent the last two years developing what we refer to
as the "Sense Framework" for use in enterprise environments.  This
framework came about as the result of research into the various
mechanisms and components required to handle event notifications
among disparate applications, including the integration of existing
printer management products.

The trouble appears to revolve around the fact that everytime I try
to describe Sense, I always describe the architecture from the top
down.  That is, I describe the components and mechanisms that have
been designed to date, without first adequately describing why we
designed the architecture the way that it is.

What is needed now, IMHO, is a series of discussions that focus on
the architecture from the bottom up, and not from the top down.  In
addtition, more focus must be made on how Sense can be used within
embedded environments without the need for an intermediate server,
as commonly described in the current documentation.

Therefore, I will be posting messages to the Sense mailing list in
the very near future that describes the requirements and features for
event messages as it pertains to network printing, without bringing
the existing three-tier architecture into the discussion.  This should
result in a bottom-up approach to the problem domain that should
serve to foster an understanding the Sense architecture as currently
defined.

I would kindly ask others in the PWG community to offer their insights
as to how we can advance the Sense effort, or describe similar failings
to date in getting this effort moving.

Thanks for hitting me in the head with a 2-by-4, Dave.   ;-)
 
	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Tom Hastings <[email-masked]>
Date: Tue, 4 Nov 1997 09:59:53 PST

Jay,

To followup on the suggestion for a bottom up approach for embedded
implementation, I'd like to suggest that it be for an embedded IPP
printer. (Jay, consider this a second 2x4).

There should be a white paper that describes the scenario for bringing
up a SENSE server and the IPP printer with an embedded publisher.

The white paper must describe each property that the publisher puts in
the publication and in the edition and that a subscriber can query.  
Then we can get clients that would interwork with the SENSE server and 
the embedded IPP printers.

This white paper should be developed quickly, so that SENSE could be
considered as one of the (or the only new?) notification method for
IPP.

To me SENSE is like SNMP.  You need a MIB spec before you can get any
interoperation between one vendor's client and another vendor's server.
The white paper that I'm proposing is like a MIB spec.

Without such specifics for IPP, SENSE is just a general mechanism that
can do anything.  But without these agreements there can be no interworking
between different vendors implementations.

Also forget the requirements.  SENSE is obviously very general.
No one is questioning that.  Lets "cut to the chase" as you are fond
of saying, and get a spec for IPP's use of SENSE.  Maybe you even need to 
coin a term for the spec that says how a particular set of developers 
use SENSE for a particular application, something like a "SENSE profile".

I think we need an IPP profile spec first.  Then we can see if there also
needs to be a general printing profile, or whether the IPP profile really
works for most printing.

So the IPP profile spec needs:

1. List the publication properties by name and semantics.  Tying them
to IPP attribute semantics will make this much faster to write and
understand.

2. List the edition propertied by name and semantics.  Same as the
publication properties.

3. Indicate the scenario of populating the SENSE server.  Who does what.

People will go read the SENSE documentation to get what they don't
understand from the first draft "SENSE IPP Profile".

Tom

---

From: Jay Martin <[email-masked]>
Date: Tue, 04 Nov 1997 14:00:49 -0500

Tom,

I'm not sure we're on the same wavelength here.  Maybe you can help
me understand your position a bit more clearly.

> printer. (Jay, consider this a second 2x4).

Talking about requirements for an embedded IPP printer is fine,
however it should be noted that Sense pre-dated IPP by over a year,
and I really don't want to ignore the original requirements.
(And thanks anyway, but one 2x4 is enough for me right now.)

More importantly, though, is the need to get a firm consensus on
the underlying requirements of event notification in the printer
environment.  That is, before we talk "spec" with regard to IPP,
we really should be talking about the general feature requirements,
including proposed scenarios described who needs what kind of events,
and what kinds of components are expected to handle those events.

> [...snip...]

If you want to see such a white paper *very* quickly, then perhaps
you can write one yourself?

> use SENSE for a particular application, something like a "SENSE profile".

Forget the requirements?  Beg your pardon?

Sure, I like cutting to the chase, but that doesn't mean you
jump clear over the primary issues that need to be resolved.

> needs to be a general printing profile, or whether the IPP profile really

Sure, that is certainly one approach to spec'ing out things.  But
as I said earlier, we first need to talk about what an "event" is,
and who (and what) produces/consumes an event.

> 3. Indicate the scenario of populating the SENSE server.  Who does what.

I don't think we should be necessarily talking about a "Sense server"
at this point.  Instead, let's just focus on the producers and
consumers of events, then see where we go from there.

I think it was Carl-Uno who said (during the Boulder meeting) that
he'd like to see how Sense would work without having an intermediate
server.  Upon further consideration, I now tend to agree.  And that's
what I believe the Sense project should be focusing on at this time.

> understand from the first draft "SENSE IPP Profile".

As a generic observation, that's a good point, Tom.

Do others in the Sense group agree with Tom's approach, or would you
prefer to take my previously published approach of "starting from the
beginning" and getting the basics down first?

	...jay

--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --