river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Scheifler <Bob.Scheif...@Sun.COM>
Subject Re: SourceAliveRemoteEvent Part II
Date Wed, 06 Jun 2007 17:30:31 GMT
Mark Brouwer wrote:
> Funny though that you really read those postings carefully, but you
> always seem to miss direct questions like "whether an inverted event
> model is desirable?".

(I didn't miss it.)

>> The existing event listener could be called.
> I think I don't get the picture yet. Are you saying the current
> RemoteEventListener ( notify(RemoteEvent) ) is going to be called by the
> event producer to find out about reachability before granting the event
> registration?


> If that is the case that would mean the remote event
> listener would have to consume a 'throw away' event.

It's no more throw away than the first SARE.

> Staying in the lookup service example
> are you looking for a getState() method that would be able to reproduce
> the complete state of all the services registered at the moment of
> invocation, filtered using parameters matching those on the various
> lookup methods, *together* with the last sequence number that has been
> 'incorporated' in this view.

I don't know if I understand you, and I don't know for sure what I'm
looking for (it may be one of those hard problems).  If you think of
an event registration as expressing interest in a sequence of state
transitions, you could imagine the "last state" being held as part
of the registration, and a getState that could query it, along with
the sequence number for that state.  Or, if all service state changes
as a whole could be (arbitrarily) sequenced, then state lookups on
the service could contain the state sequence number, and events could
contain not only the event sequence number but also the service's global
state sequence number.

> If the above is correct I doubt whether such a generic getState() method
> could be designed for each and every event based service, it might seem
> it could be too problem domain specific.

Yep.  I'm tending to be more interested in design pattern than strict
API reuse to start in this area.  In hindsight it's not clear to me how
much value the Jini uniform event&listener API has really brought us
(could well be that it has and I just don't know it).

> 1) do you think it is generic (enough) an event producer should able to
>    notify a client of its ability to deliver events in the case there
>    are no events to notify the client of;

I'm not particularly convinced yet that heartbeat events should be
intrinsic to all event registrations.

> 2) do you think it is essential a client must be able to find out
>    whether an event producer is able to deliver events at all;


> 3) do you think an event driven programming model should be possible
>    without having the ability of callbacks from the event producer;

It's clearly possible, so you must have meant a different question.

- Bob

View raw message