|
From: B. <jer...@xt...> - 2002-01-31 10:33:11
|
Bordet, Simone wrote: >>The >>problem with this scheme is that you should try to send some >>few times >>the notification (there might be a network congestion for >>example) if it >>does not work the first time. The call should be threaded too >>because we >>do not want to block the server while calling the client. >> > >No, I do want. At least must be sequential the call for filtering and notification... >Actual implementation is in same thread however: for server there is no difference between local and remote (I know, I know... :) > If you want to garanty order then if you have one remote reference that is "dead" (because of network failure or client crash), you will block the server on this item and the other notifications won't be sent before a while. Is it really important to have a sequential order of notifications? What about adding (like Jini) an eventID and increment this ID each time a notification is sent. That way the client can "re-construct" the order if it matters. Jerome. |