We cannot throw our functionality into a client. We are resident in the space.
Sent from my iPhone Michael McGrady Principal investigator AF081_028 SBIR Chief Architect Topia Technology, Inc Work 1.253.572.9712 Cel 1.253.720.3365 On Dec 3, 2010, at 6:45 PM, Peter Firmstone <j...@zeus.net.au> wrote: > As I suspected the suggestion would reveal Michael's needs for RTSJ. > > We've established no one needs a real time server PLATFORM service, this > means that the existing service implementations don't need to run on RTSJ, > only the proxy's and a core platform for producing application services. > > If we make River modular, Patricia can work on the Javaspace server > implementation so it can utilise the latest platform concurrency features. > Therefore to run a Javaspace server, it must be installed the Java 1.6 > platform. The same can apply for Reggie, Mahalo and all the other service > servers. > > You can still use a Javaspace service on a RTSJ client, to produce > information for the Javaspace cloud, where it can be processed using the > producer consumer pattern. > > Modularity is the Solution to multi platform support. > > Where earlier Java platforms can participate, but don't provide platform > services, only consume them. > > The Service Implementations need to be separated from the River Jini Platform > codebase. > > This massively reduces the maintenance required to support earlier platforms. > > I don't need to run any Platform service on BlueRay either. > > Even if we don't call it modularity, River should be broken up, all the > services can be subprojects, they can evolve at their own pace and needs, > without being held back by earlier Java platform support requirements. > > Cheers, > > Peter. > > MICHAEL MCGRADY wrote: >> That is correct. I do not think that River would be interested at this time >> in real-time constraints. It is too big a jump for this place in the >> history and I am just asking for an incremental move to Java 1.5 from Java >> 1.4 to remain consistent with real-time JVMs. >> >> MG >> >> On Dec 2, 2010, at 11:38 PM, Patricia Shanahan wrote: >> >> >>> I think we may be getting distracted from the key objective if this thread, >>> nailing down our JVM version policy for the next few releases. >>> >>> Do we have any indication of a need for real time constraints in River? I >>> don't think Michael has asked for anything beyond keeping River JVM version >>> compatible with Java RT. >>> >>> Patricia >>> >>> >>> On 12/2/2010 10:50 PM, Peter Firmstone wrote: >>> >>>> What I'm trying to say is, that a Service and Client each running on >>>> RTSJ, could set real time constraints, as we now might set a >>>> ServerMinPrincipal constraint, meaning that if real time was required >>>> over EtherCAT, this could be supported by some services and clients that >>>> require it while others may not require it in the same environment. >>>> >>>> Currently constraints are used to enforce: >>>> >>>> 1. Confidentiality >>>> 2. Integrity >>>> 3. Authentication >>>> 4. Authorization >>>> >>>> If we supported RTSJ we could add: >>>> >>>> 5. Real Time >>>> >>>> Just a thought. >>>> >>>> >>>> >>>> Mike McGrady wrote: >>>> >>>>> Abandoning Java RT is not in the cards for us. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> Michael McGrady >>>>> Principal investigator AF081_028 SBIR >>>>> Chief Architect >>>>> Topia Technology, Inc >>>>> Work 1.253.572.9712 >>>>> Cel 1.253.720.3365 >>>>> >>>>> On Dec 2, 2010, at 10:12 PM, Peter Firmstone <j...@zeus.net.au> wrote: >>>>> >>>>> >>>>>> It may be possible to add real time constraints. >>>>>> >>>>>> For example, EtherCAT supports real time networking, a client and >>>>>> server could set a real time constraint and communicate over EtherCAT. >>>>>> >>>>>> The question that Dennis has posed though is how much do you need? >>>>>> This doesn't have to be decided now, perhaps you can set up an issue >>>>>> on jira so we can track it. >>>>>> >>>>>> The current release still runs on Java 5. The next release due soon >>>>>> will too, the following release may not, but time will help us decide >>>>>> how solve this problem. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Peter. >>>>>> >>>>>> >>>>>> Dennis Reedy wrote: >>>>>> >>>>>>> What boggles my mind here is adding real-time requirements in the >>>>>>> same context of Jini. While you may have real-time threads, once you >>>>>>> touch the network your real-time QoS goes out the window. You may be >>>>>>> able to guarantee that the amount of time it takes to perform an >>>>>>> operation will be done within a bounded time, but you will not be >>>>>>> able to guarantee (in a real-time context) that the result of that >>>>>>> operation will be transmitted over the media to a requesting client. >>>>>>> >>>>>>> What I'd like to find out from Michael here is what exactly are the >>>>>>> RT requirements for River? >>>>>>> >>>>>>> Service Infrastructure (JoinManager and the like...) >>>>>>> Services (Reggie, Mercury, Outrigger, etc...) >>>>>>> >>>>>>> Other? >>>>>>> >>>>>>> >>>>>>> On Dec 2, 2010, at 104AM, MICHAEL MCGRADY wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> We do this now with Java 1.5, Greg. Java RT 2.1 (64 bit) is >>>>>>>> compatible with Java 1.5. http://preview.tinyurl.com/2bpjqfh There >>>>>>>> would be no other test than works-with-Java-1.5. The simple answer >>>>>>>> is that if River does not call real-time threads and uses Java 1.5 >>>>>>>> there is no issue. There are other things that impact real-time but >>>>>>>> we can cover those. >>>>>>>> >>>>>>>> MG >>>>>>>> >>>>>>>> On Dec 1, 2010, at 9:00 PM, Greg Trasuk wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, 2010-12-01 at 23:33, Mike McGrady wrote: >>>>>>>>> >>>>>>>>>> Like I said, Java 1.6 is incompatible with Java RTS and that os >>>>>>>>>> very serious in my neighborhood. We do QoS with Java RTS. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> That's certainly an interesting comment... I'm curious though: I >>>>>>>>> haven't >>>>>>>>> looked at RT Java for several years, but I recall that the first pass >>>>>>>>> allowed plain Java (i.e. non-real-time) to be executed. Would River >>>>>>>>> components need some other evaluation or testing to be accepted as >>>>>>>>> "real-time" (which I doubt would be an easy task), or would you >>>>>>>>> just be >>>>>>>>> looking for compatibility with the run-time environment, but without >>>>>>>>> real-time guarantees? >>>>>>>>> >>>>>>>>> Also, what would be the impact if the RT system called services that >>>>>>>>> were resident in a non-RT virtual machine? Specifically, would the >>>>>>>>> registrar and/or JavaSpaces implementation need to be hosted in a >>>>>>>>> Java >>>>>>>>> RTS virtual machine? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Greg. >>>>>>>>> >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>>> Michael McGrady >>>>>>>>>> Principal investigator AF081_028 SBIR >>>>>>>>>> Chief Architect >>>>>>>>>> Topia Technology, Inc >>>>>>>>>> Work 1.253.572.9712 >>>>>>>>>> Cel 1.253.720.3365 >>>>>>>>>> >>>>>>>>>> On Dec 1, 2010, at 5:03 PM, Patricia Shanahan <p...@acm.org> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 12/1/2010 4:53 PM, Dennis Reedy wrote: >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>>> Some of the discussion has referenced Java CDC on BlueRay. Should >>>>>>>>>>>> these platforms have an overriding influence on whether River >>>>>>>>>>>> moves >>>>>>>>>>>> forward and adopts 1.6 as a baseline? I'm not so sure at this >>>>>>>>>>>> point. >>>>>>>>>>>> >>>>>>>>>>> Is the relevant Java dialect identical to 1.4? If not, we would >>>>>>>>>>> need a separate project to make portions of River run on it. >>>>>>>>>>> >>>>>>>>>>> Patricia >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Greg Trasuk, President >>>>>>>>> StratusCom Manufacturing Systems Inc. - We use information >>>>>>>>> technology to >>>>>>>>> solve business problems on your plant floor. >>>>>>>>> http://stratuscom.com >>>>>>>>> >>>>>>>>> >>>>>>>> Michael McGrady >>>>>>>> Chief Architect >>>>>>>> Topia Technology, Inc. >>>>>>>> Cel 1.253.720.3365 >>>>>>>> Work 1.253.572.9712 extension 2037 >>>>>>>> mmcgr...@topiatechnology.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >> >> Michael McGrady >> Chief Architect >> Topia Technology, Inc. >> Cel 1.253.720.3365 >> Work 1.253.572.9712 extension 2037 >> mmcgr...@topiatechnology.com >> >> ------------------------------------------------------------------------ >> >> >> >> >
