[opendtv] Re: OCAP - will it continue to move forward
- From: Bill Sheppard <Bill.Sheppard@xxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Fri, 15 Oct 2004 01:20:36 -0700
[OK, this time will really work!]
Kon Wilms wrote:
>Bill Sheppard wrote:
>
>
>>>Wilms wrote:
>>>You said the magic phrase 'well-defined'. I translate that to mean
>>>'restricted to'. Hence the assertion of 'run once debug everywhere' is
>>>correct.
>>>
>>>
>>You might choose that translation, but it's not relevant. Java spans
>>from 8-bit microcontrollers to 64-bit CPU's. To expect the same
>>application to run across this breadth of hardware is neither realistic
>>nor useful.
>>
>>
>
>So what you're saying is that your kool-aid can't really be sold at all
>the lemonade stands. And it matters what glass you pour it into.
>
>
Of course it matters. If you served lemonade in shot glasses you'd have
very little repeat business.
>Thanks for admitting that Java indeed can not run everywhere. That's a
>first!
>
>
The Java language can run (essentially) anywhere. Java platform
specifications are wisely targetted to be appropriate to the market for
which they are intended. It makes little sense to attempt to support
J2EE capabilities on a cell phone with 512K of memory and a 40 MHz
processor.
>>>In terms of these platforms that a Java application is restricted to,
>>>will the same application that runs on a Nokia NGage run on a Siemens
>>>C55? Both use 'Java Technology'
>>>
>>>
>>Many applications will. And were these phones compliant with more
>>recent industry-defined specifications, such as MIDP 2.0, a much larger
>>selection of applications would be compatible without specific debugging
>>effort.
>>
>>
>
>Well yes, but with restricted user experience, making it harder to
>charge that extra buck for the top of the line phone.
>
>
Just as Doom 3 will only run satisfactorily on a high-end PC, there is
certainly a class of applications for which the mass-market phone may
not be suitable. Nonetheless, just as virtually any entry-level PC
today is wholly sufficient for the vast majority of everyday uses (i.e.
email, browsing, word processing, chat, etc.), most MIDP 2.0-based
mobile phones will be sufficient for most applications.
>Are you saying that MIDP2 requires no specific debugging, and that it
>will run on a 'specced' platform with zero test? Is that something Sun
>stands behind? I'm not discounting MIDP - Sun went after that and
>actually produced something good.
>
>
Of course you can't claim no specific debugging and zero test in all
cases, but MIDP 2.0 added support for many of the areas which had
required proprietary vendor-specific API's in the past, such as sound.
Sun's Wireless Toolkit (WTK) is a PC-based implementation of MIDP which
most developers use as their development platform, and includes skins to
emulate various mobile phones. I believe you will find developers are
very pleased with this approach - in fact, it was selected as 2003
Development.com Wireless Development Product of the Year.
Further assurance can be provided by JavaVerified.com. For a few
hundred dollars developers can submit an application to be certified
across a range of actual handsets, providing assurance to operators that
applications will execute properly across their installed base of
phones. T-Mobile and Orange recently announced they would require
third-party applications to undergo JavaVerified certification. This is
a model which might be very appropriate for the DTV market as well.
>>>http://www.comp.lancs.ac.uk/computing/users/fittond/ppcjava.html
>>>
>>>
>>And proves my point. The chart indicates VM's implementing more than
>>four completely different Java specifications targetting completely
>>different devices, plus VM's which have not passed any proper Java test
>>suite. MHP and OCAP have extensive test suites which all devices will
>>be required to pass; no ambiguity about what specification is being
>>implemented. This makes for a far more consistent environment for
>>developers. Of course, memory, CPU, graphics capabilities, and the like
>>will still vary from box to box, but the vast majority of OCAP
>>applications will run across all boxes with little-to-no debugging
>>across devices.
>>
>>
>Obviously you have not used some of the VM's on that list. To say some
>lack features and others have 'issues' would be an understatement. There
>is nothing consistent in the fact that there is a 'selection' of VMs.
>This development mode is more time consuming because one has to eval all
>the platforms, go through their documentation, have a test application
>to do speed comparisons, and then jump for one and hope there are no
>undefined bugs in the VM implementation. I'll stick to that C99, thanks.
>
>
Rather than going through the process you outlined, the "proper" method
would be to select the appropriate Java specification for the device
(for a PocketPC that would likely be CDC/FP/PBP or PP), then choose from
among the implementations that are certified compliant to that
specification. Certification provides a high degree of confidence that
you'll not be impacted by bugs in the VM implementation. Most of the
products listed in that table come from "garage-shops" implementing
arbitrary collections of Java API's (in violation of the copyright
granted by the Java language specification requiring all VM
implementations to conform to recognized specifications) and aren't
suitable for production-quality applications.
>As for a spec to stick behind, remember when Java for STBs was called
>Personal Java, then J2ME, now J2ME fragmented into a family?
>
>http://java.sun.com/products/personaljava/index.jsp
>
>
>Those hardly ran a few years and then suddenly reached 'end of life'.
>
It's not nearly as dire as you paint it. PersonalJava is the
specification MHP and OCAP are based upon (the bulk of the work having
been done in 1998). It was superseded by the J2ME architecture a few
years later. J2ME introduced a much higher degree of modularity, and
includes the CLDC branch for small devices (i.e. cell phones) and CDC
for more capable devices (i.e. set-top boxes). MHP and OCAP can be
implemented on either PersonalJava or the CDC/FP/PBP stack; applications
can't tell the difference. New API's are added to J2ME all the time to
address new industry requirements (i.e. Bluetooth, XML, OpenGL, etc.),
but these all build upon either CLDC or CDC and don't obsolete the
existing specifications.
>I can only conclude that it must have been those pacman-clone demos
>running at 5fps on the JVM for STBs in NAB2000 that killed it.
>
Both VM technology and STB capabilities have come a long way since
then. And nothing's been killed - MHP and OCAP are alive and well.
You'll see.
--
-------------------------------------------------------------------------
Bill Sheppard Industry Marketing Manager
bill.sheppard@xxxxxxx Consumer and Mobile Systems Group
(408) 404-1254 (x68154) Sun Microsystems, Inc.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
