I'm not sure we're on the same wavelength here. Maybe you can help
me understand your position a bit more clearly.
> 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).
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.
> There should be a white paper that describes the scenario for bringing
> up a SENSE server and the IPP printer with an embedded publisher.
>
> [...snip...]
>
> The white paper that I'm proposing is like a MIB spec.
If you want to see such a white paper *very* quickly, then perhaps
you can write one yourself?
> 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".
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.
> 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.
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.
> 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.
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.
> People will go read the SENSE documentation to get what they don't
> 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
----------------------------------------------------------------------
-- 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 --
----------------------------------------------------------------------