On Mon, 2005-01-10 at 22:47 +0100, Stefan Lischke wrote: > Hi, > > Samuel Meder wrote: > > > I would propose the following instead: > > > > > I have put your updated proposal into java and UML. So we have something > to work on: > > http://www.ivs.tu-berlin.de/Lischke/blog/archives/2005/01/hermes_api_prop.html > > Please have a look at the Sequence diagram, thats the way how i imagine > this API works for subscriber and publisher (and also the broker) you > are d'accord?
Seems reasonable. > I have added the following. > > NotificationConsumer: > //Thats the callback method that is called when a notification arrives > void deliver(Filter f, EndpointReference epr, Object message) > > //Thats the callback method that is called when a Subscription End > notification arrives. > //think about parameters !! > void end(....) > > One question, can you tell me for which use is the > NotificationConsumerFactory? I was thinking it would allow one to supply different types of notification consumer endpoints (raw vs wrapped deliver for example). > IMHO each API user creates his own callback implementation which is > derived from NotificationConsumer. So what for a Factory? > > and for what are the get/setEPR in the NotificationConsumer interface? to get (maybe set is redundant) the endpoint reference for the consumer so it can be communicated in the subscribe call. I also realized that I forgot the policy field in the subscribe call. /Sam > stefan > > -- Sam Meder <[EMAIL PROTECTED]> The Globus Alliance - University of Chicago 630-252-1752 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
