My point is that the Producer does not always know what "each consumer"
means.
Subbu
Rich Thompson wrote:
>
> Interesting questions. Other than the last one, they all seem predicated
> on an implementation style that tracks changes and does a computation
> upon interaction to determine whether or not to generate one of these
> events. Another implementation choice (that happens to avoid the bulk of
> these issues) is to persistently store the need to provide one of these
> notifications to each known Consumer and then delete the record saying
> the need exists when it is delivered. In addition to removing datetime
> computation while processing a request, this also permits notification
> by means other than event delivery. An example of this would be to
> consider a getServiceDescription invocation as removing any
> Producer/Portlet metadata change notifications as the response will
> already update the Consumer.
>
> The other point about these event definitions is that their purpose
> would not be to require any particular functionality, but rather to
> provide a standardized means by which a Producer could proactively
> inform a Consumer about changes. Whether or not a particular Producer or
> Consumer implementation makes use of this means to reduce polling for
> metadata would still be entirely implementation dependent.
>
> On the last question, I do not think it is up to the spec to define what
> a change is that should trigger any of these notifications. Rather they
> are defined as a means for carrying a notification that a particular
> form of metadata has changed. As a result of this, I would resist
> optimizations such as having the ProducerMetadataChanged event payload
> carry the new ServiceDescription. Instead, the event is just a
> notification and it is up to the Consumer to decide when and how to
> respond to the information.
>
> Rich
>
>
> *Subbu Allamaraju <>*
>
> 03/10/05 10:57 AM
>
>
> To
>
> cc
>
> Subject
> Re: [wsrp] Spec defined events
>
>
>
>
>
>
>
>
> > As to other options to carry such notifications by other means, why
> > would we add such dependencies when we already have a channel that could
> > easily carry the information. I agree that the Consumer is not likely to
> > display the fact that it received such an event to normal end-users, but
> > it certainly would be valuable info to display to system admins (or
> > queue for display to them).
>
> Thanks Rich. You make some good arguments. So, let me counter with few
> more questions.
>
> o Producers don't necessarily know whether the Consumer's version of the
> Producer's metadata is current or not, unless it starts to keep track of
> all metadata requests.
>
> o The Producer has to keep track of metadata changes persistently and
> make sure to cleanup those changes periodically.
>
> o The only time a Producer could return events is via handldEvent(s) and
> pbia responses (excluding fault conditions). This may be acceptable.
>
> o Assuming that the Producer recognized a change, how would it know
> whether a given Consumer should be notified or not? Should it start
> sending notifications to all Consumers (including those that already
> have the current metadata)? Such Consumers will have to do some extra
> processing before ignoring the event.
>
> o Should the Producer keep sending events for ever or just once? It
> can't be the latter since the Producer does not always know about
> Consumers. So, it does not know which Consumer was already notified.
>
> I think, a more fundamental question how would the spec define what a
> "change" is.
>
> Regards,
>
> Subbu
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
