Bob Scheifler wrote:
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).
Maybe I'll start another thread on this one as I think we are getting to
a fundamental issue here, namely which part of the specifications do
have value, why didn't Jini grow to what was envisioned in 1999 and why
is it that things that make sense are not being used. Whether this can
be altered, how it should be altered, whether that is the task of River
or that we should all stop and say with Whiskey next to the fireplace
"in 1999 they came up with something promising, but it all ended up with
playing around a JavaSpace and using discovery and as such it failed in
its envisioned goals".
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.
And for that reason I like the idea of an optional constraint, some
service specifications for which it makes sense can require a compliant
service to have support for the constraint.
The fact something is not intrinsic to all event registration doesn't
mean to me it doesn't have its place to be standardized considering it
is optional.
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.
I think I try to ask whether you think an inverted event model should be
'standardized' as a mandated or optional feature of ServiceRegistrar,
JavaSpace, etc. and be on par with the Jini Distributed Event specification.
--
Mark
