Kon Wilms wrote: >Bill Sheppard wrote: > > >>Sure, you can create some library portability. But if it's C/C++ you've >>still got to recompile the code based on the underlying hardware >>platform, and that means delivering a binary application over the >>network to a diverse range of devices becomes exponentially more >>complicated (and hence expensive). Plus the fact that "direct >>interfacing to the system level/kernel is much easier" also means that >>crashing the system or accessing hardware apps ought not access is much >>easier, too. >> >> >This reply verges on ludicrous. You're painting this picture that >without Java programmers are lost and all we have is unreliability and >failure to operate. Not so. For portability we have middleware and the >likes of Cint, CH, and others. > > Maybe in theory, but show me a single widely-deployed binary portable C-based application in the ITV world. Doesn't exist. MHP and OCAP are changing the landscape. >>Right. And the certification process for Motorola and Scientific >>Atlanta to ensure that C/ASM/C++ code is reasonably secure and bug-free >>is so onerous (read expensive and time-consuming) that it's virtually >>impossible to develop third-party applications for these boxes, and why >>so few applications beyond EPG and VOD have been developed in the US, >>versus the UK and elsewhere where virtually every program has some form >>of interactivity available to the consumer and generating hundreds of >>millions of pounds of revenue for Mr. Murdoch. >> >> >Even though its great to have all this cross-platform stuff, pay tv >operators run in a walled garden. > And increasingly we have the ability for non-pay TV operators to provide applications as well. The garden walls are slowly crumbling. >Just allowing anyone to run an application anywhere brings with it a set of >problems that are not at >all technology-based. > > Some technology-based, some policy-based, but the profits are sufficient to motivate the industry to solve them. >These boxes by the way also have constrained memory and processor >requirements, making it impossible to throw Java on them. If you want to >make games for them, sit down and open your C books and get started. > > Mobile phones have constrained memory and processor requirements, yet there are thousands of Java-based games. The US cable industry is creating OnRamp to OCAP, a constrained Java-based subset of OCAP which will run all the way down to a 2MB DCT-2000. It won't be pretty, but it'll be Java and it works (see Liberates Compact platform already deployed, it's an implementation of this specification, and it plays games). >The hundreds of millions of pounds from applications aren't coming from >Java applications. They are coming from C code. > No, they're coming from OpenTV apps or from WTVML apps. >I'm sure there are other arms of uncle Rupert's empire playing with Java. > > DirecTV's updated platform due any day now is Java. Otherwise there is little if any Java deployed in his settops. >>>As for security, my previous employer was in the business of smartcards. >>>Java had no place there. >>> >>> >>And JavaCard now accounts for over 96% of the smartcard market. You >>couldn't have proven my point any more effectively! >> >> >We're talking about broadcast markets. NDS had at last check 20 million >smartcards deployed. Directv, Sky, ... no JavaCards therel, sorry. > > True. I thought you were referring generically to smartcards, not to proprietary conditional access cards. >>How are you going to deliver the application allowing you to vote for >>your favorite American Idol in flash ROM? The whole point of MHP and >>OCAP is to allow for the efficient development and secure delivery of >>third-party applications. >> >> >You do it the same way it has been done since the first STBs rolled out >- by carousel. Target it to the boxes by smartcard or other ID, and let >them execute or self-update. The majority of boxes either run out of RAM >and do updates from a reserved flash area, or can bootstrap an update. >Nothing new here, been doing this since there was only a few hundred Kb >available for flash storage. > > And you think this model will be feasible for a new application for every show on every channel? Flash is for the monitor app or the EPG, maybe the VOD client, not much else. Everything else lives in RAM. >Really, to say 'how will this possibly be done without Java, MHP and >OCAP' is just absurd. > > A robust third-party ecosystem of applications requires the frameworks enabled by MHP and OCAP. You simply can't integrate all these third-party apps without the security a VM provides. If you could why wouldn't a single US MSO have rolled out applications to their PowerTV or Motorola settop boxes? They haven't, unless they're using a middleware environment from ICTV or a small handful of others, none of whom have achieved even a tiny fraction of market share. >However I'm not discounting Java. Everything has its place and its use. >Just don't try to force it down my throat as the do-all end-all with >rubbish like 'required if you want real security' and 'required if you >want your application to run everywhere'. Thats precisely the attitude >that turns people away from Java, and I've witnessed it way too many >times for it to be an anomaly. > Maybe, but the TV standards community has completely standardized upon it, and with the possible exception of Microsoft continuing to evangelize .NET, no other platform is anywhere on the horizon in terms of likely deployment. Bill -- ------------------------------------------------------------------------- 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.