> I agree that the subscriber should be able to indicate whether he/she
> want reliable or unreliable. (It shouldn't be a propertly that only
> the publisher sets.)
I agree 100%. No issue here.
> I thought that there was a property in the edition that specified the
> number of re-tries before giving up. Since there must be a separate
> counter for each subscriber to keep track of how many retries have been
> made, couldn't the subscriber also specify the number of retries when
> subscribing?
No, there is no "retry" property in an Edition. Retries are handled
at the client level; that is, during client registration and potentially
at per-Edition subscription time.
In other words, I believe Sense is already designed to handle what
you'd like to see, and if there are any holes remaining, we can
certainly fill them using the kind of approach you and Harry have
suggested. No issue here.
> A value of 1 would mean unrealiable.
Actually, I'd suggest a value of 0 to indicate "no retries" (ie, a
retry count of zero). Seems to be more elegant and useful, no?
To make this message a bit more readable, I have included the rest
of your message (with Harry's and my embedded comments) at the end
of this message. Following are my comments to that text.
First, I think we're pretty much in agreement with the basic Edition-
oriented philosophy that precludes the need for extensive filter
specification, etc. (I realize Harry may not agree with this.)
As you mention, the prior established specifications for IPP job-
related events reception by a client are:
none
all
job-completion
job-problems
job-started-processing
printer-problems
Of course, in the case of Sense, the "none" case is not relevant;
the Subscriber client simply does not subscribe to any of the
associated Editions.
Separate Editions can be designed for the remaining types, though.
To keep life simple, it would be best for us to focus on the "all"
case, since I honestly believe this specification will be used by
most clients. (Agreed?)
What we need to do then is:
1) Name the Edition. Something like "IPP.Job.AllEvents" would
follow what we have done in the Printer MIB area, but this
choice is obviously quite arbitrary. What can be important,
though, is the left-to-right dotted-string convention for
naming things in a rough hierarchical manner.
2) Define the Event message format. A standard Edition property
(Edition.Protocol) is used for this purpose. Again, there is
tremendous leeway in defining the message format. At Underscore
we spent quite a bit of time trying to come up with a generic
event format mechanism that can work for many, many different
kinds of event scenarios. We call this the "Simple Text Event
Protocol, Type 1" (STEP.1), and documentation exists on the PWG
Sense area describing this format and how it's used.
We can take a crack at defining IPP Job messages using STEP.1,
or devise and entirely different method. Makes no difference
to us. One of the beauties of Sense is that it is defined to
allow the existence of parallel Editions, where the same content
and semantics is provided, but the format differs (for whatever
programmatic reasons that might exist).
3) Defined the exact contents of the message (independent of the
wire protocol, or "format" as I have referred previously). Here
we have a pretty simple task, since we should merely leverage
the data and format as (previously) defined in the IPP Model
document.
What I'd like to instill at this point is that defining an "Edition"
(or multiple Editions) for IPP Job events is pretty trivial...assuming
that you buy into the Sense architecture as currently defined.
We must first get the architecture right before spending time on
more concrete applications of Sense. Hopefully folks can see how
easy it would be to define all kinds of Sense Editions for IPP-related
events, but first we need to all agree on the actual architecture.
Agreeing on the Sense architecture is what I hope to accomplish at
the upcoming LA meeting next month. Assuming, of course, that more
input/comments/etc are received on the Sense DL before the end of
next week.
...jay
PS: To help folks visualize things a bit bettter, here is the full
contents of an Edition providing all device events for a printer
based on the Printer MIB:
Edition.ClientId = 6
Edition.Content = AllDeviceEvents
Edition.Protocol = STEP.1
Edition.Publication = printer/digital/lps/17|dorky|underscore.com
Id.Class = app/underscore/pa/publisher/sfplps/editions/step.1/AllDeviceEvents
Id.Client = 6
Id.Contact =
Id.Description = All printer device events
Id.Domain = underscore.com
Id.Host.Name = uscore
Id.Id = 10
Id.Manufacturer = Underscore, Inc.
Id.Name = dorky
Id.Product = PrintAlert
Id.SenseVersion = 1.0
Id.Signature =
Id.Updated = 878572337
Id.URL = http://www.underscore.com/products/pa/publishers/sfplps.html
Id.Version = $Id: .edition 1.1 1997/01/17 09:52:02 jkm Exp $
----------------------------------------------------------------------
-- 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 --
----------------------------------------------------------------------
Additional comments from Tom/Harry on message filters and IPP job
events:
> >> 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.
>
> Yes, allow the subscriber to specify a simple subset of the 6 defined
> events (actually only 4, because 'all' and 'none' are really separate
> events).
>
> In IPP, we defined the following set of events and allowed the client
> to specify any combination of them. That doesn't sound too difficult.
>
> Part of a publication should be a single property which is the names of
> the set of possible events. The subscriber specifies a property which is a
> subset of that publication property.
>
> Here is the following text from the 10/14/97 Model draft (that was
> subsequently deleted because of a lack of a transport for the events).
>
> 4.2.2 notify-events (1setOf type2 keyword)
>
> This attribute specifies the events for which the end user desires some
> sort of notification. The "notify-addresses" attribute is used to describe
> the destination addresses for these events.
>
> Standard values are:
>
> 'none': the Printer SHALL not notify.
>
> 'all': the Printer SHALL notify when any of the events occur.
>
> 'job-completion': the Printer SHALL notify when the job containing this
> value completes (i.e., enters the 'completed', 'canceled', or 'aborted'
> state) with or without errors.
>
> 'job-problems': the Printer SHALL notify when this job has a problem
> (i.e., when the job leaves the 'processing' state and enters the
> 'processing-stopped' state).
>
> 'job-started-processing': the Printer SHALL notify when the Printer starts
> processing the Job (i.e., when the job leaves the 'pending' state and
> enters the 'processing' state).
>
> 'printer-problems': the Printer SHALL notify when this job is affected by a
> Printer problem. This happens when the printer enters the 'stopped' state
> while this job is in the 'pending', 'pending-held', 'processing', or
> 'processing-stopped' state.
>
> In a create request, if the client supplies 'none' along with any other
> combination of values, it is the same as if only that other set of values
> had been supplied (that is 'none' has no affect). If the client supplies
> 'all' along with any other combination of values, it is the same as if only
> 'all' had been supplied (that is 'all' subsumes all other values).