On Dec 2, 2010, at 958AM, MICHAEL MCGRADY wrote: > There are no RT requirements for River.
Ok, good. > There is only the requirement that, if River wants to be compatible with Java > RT that it not go to Java 1.6 but stick at Java 1.5. Define compatible? In what specific areas must River be compatible with RTJ? Serialization? Where? Can you be specific? Apologies, but I'm having a hard time parsing through your statements since they are somewhat vague to me. Can you enumerate exactly what River capabilities need to be 'compatible' with 1.5? The entire stack? Portions of it? > Once you touch the network real-time QoS does not go out the window. How so? Are you saying that the network is reliable enough to deliver your request/response in a guaranteed way? Have you developed a specific protocol that is part of the JERI stack that ensure your transport has some real time context? Is River involved in this (other than from a configuration point of view), or is it similar to whats described in this paper: http://www.cs.wustl.edu/~schmidt/PDF/RT-POA.pdf > > We are bound to River-like functionality (JINI) and JavaSpaces and RT in a > network context. This statement has a ton of hidden implications. River-like functionality? This implies to me that you are doing River (Jini) like things but not using River. Is that right? JavaSpaces and RT in a network context? What does that mean?
