Originally Posted by Frank Derks
The neat trick with HDi is that the code is wrapped in a markup language.
It's just a text file.
As such in the future HDi code can be transmitted accross the web and passing firewalls etc etc.
Compiled Java code for a VM can get into trouble if firewalls see some 'suspicous' pieces of coding. At can be unintentional and harmless but it can break web interactivity.
Umm, no. Any application gateway firewall paranoid enough to be doing content analysis isn't going to be using logic like "oh, text oK, binary NOOO". Text is not harmless, as exploits from markup can easily inject viruses too. The reality is, any downloadable HDi or Java code will have to be digitally signed, probably encrypted, with integrity checks. It is not going to be as simple as it is with Web programming. This is one of the false analogies of trying to compare HDi with "web programming"
Another advantage for the xml style approach is that it's an open standard It's should be fairly easy to develop and program an menu or interactivity designer program. No more text editing required. Just paint buttons on a canvas and set property sheets to bind them to features available on disc.
Oh please. HDi is not more open than Java, less so. The Java language specifications are freely available, and the source code to several Java implementations, as well as class libraries are available. Where can I download HDi specs and source code implementations?
It is not more difficult to develop a graphical IDE for generating BD-J menus. In fact, anyone doing so would probably invent an XML scene graph format, and write a small runtime BD-J library to display it, and then create an IDE to generate it.
This way a code generator for Java can be created too but due to the many player implementations and various VM implementations developing such an application would be a daunting task.
Uh huh, and if HD-DVD "wins" and has 4 dozen players, and 5 different HDi implementations, you don't think there's going to be differences in performance and bugs and compatibility, thus making an HDi code generator as complicated as HTML code generators (like Dreamweaver which fixes up HTML to work between browsers?)
All of these assertions are nonsense. There is not inherent difference between HDi and BD-J in this regard. If you want to talk about ease of use of a high level language for newbies, that's one issue, but ease of creating multiple cleanroom implementations on different players? Completely dubious assertions.
What MS has done has builtin their own half-baked animation API, rather than providing a powerful and fast platform for creating one's own animation/timing framework.
I fully agree that if you're comparing "raw" BD-J vs HDi, HDi is easier to get started. But the real comparison will be HDi vs BD-J plus interactivity middleware-X.