Mark Brouwer wrote: > Dan Creswell wrote: > >>> Of course all of the above can be developed for each specific event >>> protocol, but in my humble experience that has proven to be a repetitive >>> task which requires less than trivial logic at the event producer >>> side. The watchdog logic at the client side is repetitive as well and a >>> lot of people dismiss remote events as being unreliable while I think we >>> have the means to alter that notion. > >> Mmmmm, I'm not sure we should alter that notion. There's more than just >> the software at work here. >> >> When we talk about events being unreliable we don't just mean that >> services go down etc. What we're saying is something like: >> >> "You need to figure out what your failure recovery processes are and >> design them into your system at human, code and hardware levels". >> >> One thing you might do is the kind of thing you're describing but it's >> not the whole picture. > > I don't disagree here Dan, reliability covers a lot of ground. But with > regard to events it is often the fact you don't know whether an event > occurred or that any of the above occurred that is inferred by it. > Otherwise we should label synchronous invocations as 'unreliable' too, > which of course we know are unreliable too ;-) > >>> For that matter I believe the pattern is that common that I consider it >>> a proper (optional) addition to the Jini Distributed Event Model and of >>> course together with the 'inverted' event model. When we 'standardize' >>> this practice we can developed the client side utilities, we can have >>> framework support for the server, but of course you are also allowed to >>> do all the heavy lifting yourself ;-). We can write articles about best >>> practices, etc, etc. Bottom line is that we should be able to create >>> event based solutions for which our friends in the 'you want data, I >>> have data' have to write oh so many lines of error prone code to get the >>> same level of robustness (or information to base decisions upon). >>> >> >> No issue there but I'm not clear on just how deeply baked in this >> support needs to be. > > Fair enough questions. To me some things only have value when we > 'standardize' it [1] (either optional or mandated) as part of the core > of Jini. Standardizing allows me to build upon or for something that is > larger than the world I'm part currently part of. > > The LUS that comes with Seven does things for people who need to cross a > firewall, but it is a propriety solution as it only works with the SDM I > supply as part of the Seven Suite. This is a situation I don't like for > various reasons and some other people also don't like because they want > to be able to swap. Some end up using it anyway because when the pain is > hard enough 'principles' fade away ... but it is far from ideal. > > If it turns out nothing needs to be 'deeply baked in' I really question > the value of continuing with Jini as to me that would mean it is > finished. It might be other tasks are more important but so far it is > rather silent with ideas and I guess nothing prevents from discussing > ideas while we are awaiting the code, I grew a beard by the way :-) > > [1] soon I'm going to stop with these quotes ... > >>> As a last note, I think the addition of such a protocol would be >>> particular useful for ServiceRegistrar. Not only would this enable a >>> test for whether callbacks can be received (Jini Distributed Event >> >> Could I not test the ability to do callbacks with something like: >> >> (1) Register a notify for a special test proxy I'm about to publish >> temporarily. >> >> (2) Register my test proxy. >> >> (3) See if I get an event. >> >> (4) If I got an event I'm all done otherwise I'll try a few more >> times. >> >> etc. > > The above assumes that you can register your proxy with the same LUS as > the LUS from which you want to receive events. This already takes a lot > of assumptions with regard to security e.g. The trust relationship for a > pull versus push event model can be completely different. > > But of course we can work our ways around everything what is missing at > this point in the Jini Specification, but at what costs and what are the > benefits compared to standardizing a common pattern. > > I'm not saying what I came up with is sound, although it represents the > pattern I developed when writing a lot of event based services and > turned out to work quite well. > > But I hope that if at least the problem resonates with people we can try > together to come up with something that takes all roadblocks into > account and the improve the current situation.
Sure, I'm with you on that - I guess maybe I'm coming from a more organic position where we do something simple that won't solve all possibilities and see what happens from there. [1] [1] The age old let's get some feedback Dan mantra. Dan.
