[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Spec defined events
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 <subbu@bea.com>* > > 03/10/05 10:57 AM > > > To > wsrp@lists.oasis-open.org > 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: wsrp-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsrp-help@lists.oasis-open.org > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]