Dan Creswell wrote: > 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. >
And I fully appreciate that may not fit well with what you want to do with Seven - probably that's something else we need to figure out going forward..... > Dan. > >
