Inverted event model and 'alive' notifications [Was: Re: JavaSpace.notify() "not reliable"]

Bob Scheifler wrote:
>> I wonder whether such a 'I'm alive' notifications have ever been
>> considered as part of the event protocol for JavaSpaces and Lookup
>> Server.
> 
> Not that I can recall.

[I cross post to [email protected] as I think this
discussion belongs there, so please follow up over there if possible]

Thanks, I don't know why I always forget to integrate the follow up
question that I now have to ask.

Bob, but others please comment too, do you think 'alive' notifications
(assuming we can figure out how it should look like) would be a welcome
(optional) addition to the Jini Distributed Events Specification. Given
my experience with distributed events I think it should, as it suddenly
makes it much less 'unreliable' and in combination with an 'inverted'
event model you suddenly have 2 event models that together remove most
motivations for not relying on distributed events. The latter doesn't
mean I think events alone are enough, contrary each API should have the
synchronous business API you use for bootstrapping state/whatever and to
be utilized for one shot queries, but events should be considered for a
more efficient and convenient way of finding out about 'events' in other
services.

Unfortunately with the destruction of the old Porter mailing list I
can't link to a discussion we once had under the subject "Proposal:
Adding synchronous("pull") semantics to the event mailbox". But we are
almost a month short from the date we can celebrate our third
anniversary of an old discussion with the (at that time) obvious outcome
;-). Near the end I asked you about your opinion whether an inverted
event model would be useful as an alternative to the existing event
model. Your answer to that question was "For now I'll reserve my
opinions.". Given your question during my presentation at JCM10 which
didn't envision ServiceRegistrarX as part of the work for River, I'm
very curious to find out your opinions at this moment [1].

Personally I would love to see the 'inverted' event model or whatever we
could/should call it as part of the core specifications developed as
part of River and see extensions of ServiceRegistrar and JavaSpace(05)
that support the event model. I've always seen the JSC API as the
vehicle to ease developing Jini service opposed to competing with the
Jini specifications itself or even to be complementary to them.

[1] The JSC Service Event Model changed a bit since that date for the
upcoming JSC 1.0 to provide some stronger concurrency guarantees
(ordering of events) and to allow for reregistration of local event
listener (in case of crashed and restarted client) but the vision behind
it is still the same.
-- 
Mark