OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]