SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : All About Sun Microsystems

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Carmine Cammarosano who wrote ()4/24/2000 6:44:00 PM
From: pmcw  Read Replies (1) of 64865
 
I posted the following questions on the jini.org forum. I'll let you know if I get any responses. From reading the sources suggested by this board I've only been able to determine the processor must be capable of running JVM to run JINI directly (it not, it can still be run by proxy).

Questions as posted:

It appears to me that there is a certain amount of fixed overhead required to implement JINI directly in any device. I guess this overhead is somewhat variable depending on the feature set of the device. I've yet to find anything (although I've looked) that describes this overhead in terms of the following:

What minimum code space does JINI require in a client and in the server ("base minimum code")?

Will JINI run code straight out of ROM or require it to run in RAM and, if so, how much RAM?

How much processing power (bits x 8, x16, x32)?

Must the processor operate at a minimum speed? Are I/O buffers required?

Must the processor be a special designed for JINI or will a standard processor already on the market do?

Will a JINI client require resident EEPROM if it is to take advantage of JINI's "adaptive" feature?

Does JINI require a separate O/S? Can JINI work with any common O/S?

Thank you for your time and consideration.

Best Regards,

pmcw
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext