Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4B71C7FD.800@zeus.net.au>
Date: Wed, 10 Feb 2010 06:39:25 +1000
From: Peter Firmstone <jini@zeus.net.au>
Organization: Zeus Project Services
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Java cdc
References: <4B70BD36.50102@zeus.net.au>  <4B70F136.5090001@zeus.net.au>
 <1265724399.26999.176.camel@cameron>
In-Reply-To: <1265724399.26999.176.camel@cameron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks Greg,

We need a home for tools like Surrogate, perhaps after River graduates, 
they can be sub-projects.

Might be time to reconsider, the cdc profile isn't as limited as it used 
to be, Arm Cortex Processor + 1GB ram + internet connection doesn't 
sound bad.   By default it can be an RMI client, has reflection, a 
URLClassLoader, throw in JERI and you've got the potential for providing 
Jini services too.  We don't need all the old superfluous RMI guff 
anyway, we've got JERI.  If we can support the Foundation Profile up, 
then we capture a larger market.  It's all Java 1.4.2 based anyway, 
piece of cake.

P.S. On second thought, it might be wiser to just extend the 
ServiceRegistrar interface to provide an ObjectInputStream of 
MarshalledObjInstances, less hassles.

Cheers,

Peter.

Here's a possibility, develop a network game or interactive multimedia 
on Blue Ray disk using River, distribute the disks with a Popular Teen 
Magazine and viola, could be the next craze:

*
Understanding the Blu-ray Profiles*

Let's go over the different versions of the Blu-ray disc specification 
that's implemented on the players that exist on the market.

The first version of the Blu-ray disc specification was released as 
profile 1.0.

The next release was Blu-ray Disc Profile 1.1, which is also called 
"Bonus View." In Blu-ray Profile 1.1, the specification required support 
for Picture-in-Picture (PiP) as well as the presence of the virtual file 
system, which must possess the capability to store at least 256 MB of data.

The most current profile is 2.0, also called "BD-Live." This profile 
requires all the features from Profile 1.1 and adds the requirement that 
an internet connection be present. Profile 2.0 also mandates that the 
virtual file system store at least 1 GB of data. Now, since a 
single-layer Blu-ray disc holds 25 GB of data, you can see that virtual 
file system in Profile 2.0 devices couldn't hold a full movie. However, 
it is large enough for your applications to utilise the internet 
connection and to store some HD video content for later playback.


Greg Trasuk wrote:
> Hi Peter:
>
> Historically, the community has always assumed that the cdc profile was
> unable to directly provide or access Jini services because of the rmi
> and mobile-code limitations.  The surrogate project was created to
> address this issue for limited (or non-java capable) devices to
> participate in Jini SOA.
>
> https://surrogate.dev.java.net/
>
> I don't know the status of Surrogate, but that would be the likely
> starting point for incorporating limited devices.
>
> Cheers,
>
> Greg.
>
> On Tue, 2010-02-09 at 00:23, Peter Firmstone wrote:
>   
>> Java cdc Personal Basis Profile (a subset of 1.4.2) doesn't have the 
>> complete rmi implementation, nor does it have MarshalledObject (I'm sure 
>> we can create our own implementation with a common interface and a 
>> Static conversion class for Java SE).
>>
>> Java Personal Basis Profile: 
>> http://java.sun.com/javame/reference/apis/jsr217/
>>
>> Java cdc (in the absence of JSR 66) is capable of serialising any class 
>> instance where the bytecode is installed locally.  It also has a 
>> reflective proxy.
>>
>> I'm considering using the OSGi mobile specification, (as part of a Java 
>> cdc River Platform), in combination with JERI to download and 
>> pre-install any absent compatible packages, dynamically on demand prior 
>> to serialisation.
>>
>> Making it possible for Java cdc to participate with compatible Jini 
>> Services.
>>
>> I think we need to create a new service lookup scheme, along the lines 
>> of Gregg's recommendations, one suitable for the internet and the cdc 
>> platform.  I was thinking of creating a new interface, with a subset of 
>> ServiceRegistrar's methods and inserting it before ServiceRegistrar in 
>> the inheritance hierarchy (to have a simpler interface without breaking 
>> compatibility), then extending our new interface to provide an 
>> ObjectInputStream that returns MarshalledObjInstance's , it can't depend 
>> on Java's built in MarshalledObject, so will have to make a static 
>> factory utility class to return MarshalledObject or MarshalledInstance's 
>> for Java SE.  By using a stream, we can discard results we don't want, 
>> without filling up our memory.
>>
>> Cheers,
>>
>> Peter.
>>