river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: Environment Spec? [was; drop JDK 5 compatibility]
Date Sat, 12 Feb 2011 12:41:56 GMT
Isn't OSGi now distributed?  See Fuse 4.0.

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 Feb 12, 2011, at 3:03 AM, Peter Firmstone <jini@zeus.net.au> wrote:

> Niclas Hedhman wrote:
>> On Sat, Feb 12, 2011 at 8:57 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>>> Note that I too develop using Java 5 language features, so I'm not placing
>>> any constraints on where River's headed, I accept recent developments,
>>> people have their goals and dropping 1.4 compatibility seems the easiest way
>>> to achieve them.
>>> I would encourage people to open their minds to the investigation of modular
>>> development, Java 7 and 8 are around the corner and the same thing will have
>>> to happen for Java 5 at some point.
>> Doesn't these paragraphs capture the need for a new specification? A
>> standardized way to specify the "Minimum Runtime Requirement" for the
>> Service Proxy, so that lookup operations can ensure that clients only
>> find compatible proxies...
>> Not only would JRE variant be needed, but potentially also OS, network
>> features, and if you envision Android client deployment down the line,
> Actually I've investigated the Android option, no RMI classes I'm afraid, the security
models also different, so it would definitely be a break with compatibility.  Still there's
no reason such a thing couldn't be created and some sort of bridging service utilised.
> Yes I've wondered how a service might communicate what platforms it supports or what
version bytecode it's jar archive contains (eg dalvic or whatever they call it, bytecode version
48, 49 etc) or even let the client select from a list of archives based on it's platform,
there's no reason the service can't provide alternatives.  You could use an Entry for services,
but that wouldn't work for Discovery, where you'd just have to discard incompatible registrars
and try again.  It would be pretty easy to set different groups for different Java OS versions
etc.  It's an interesting road...the potential is here, but I get the feeling people just
want to focus on the particular platform they're interested in at the moment.
>> you would probably also like to include incl/excl of GPS, camera,
>> compass and other physical devices and their respective properties
>> (e.g. resolution, accuracy,...)
> Hmm a GPS entry...   My main focus is to continue encouraging people who take the time
to read the code and ask questions to get involved, so we grow our pool of developers, who
knows this sort of thing could be taken up as people become more familiar with River, or new
interested devs join.
>> (Forgive me if I have missed this and this is already part of the core specs.)
> That's cool, it isn't.
> Cheers,
> Peter.

View raw message