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.
