jeff_rigby
Banned
I understand that the "XMB" is the full screen framework that everything writes to and that it does have "windows". You are arguing the task level these windows can be opened, or how easily or with "standards" doesn't make them independent real "windows" like a X11 windowing system which supports among other things boarders and chrome around the windows and remote desktop and redirecting streams. That's true and only shows Sony made a custom "desktop with a subset of the same functionality..You're still not getting my point. All of the stuff you're talking about is probably all being done by the XMB itself. The video "windows" and such are not the same as a "window" that you would see on a desktop computer. They are most likely just part of the overall image that the XMB is rendering. Calling them "windows" implies a degree of separation that doesn't really make sense. Using a full window system in this context would be highly inefficient.
All this is essentially the same misunderstanding of a browser desktop.I take issue with calling the console UIs "desktops" because they are so far removed from the actual desktop metaphor that desktop computers use. This is admittedly getting into semantics, but given some of the other assumptions you're making, I feel the need to clarify.
Also, as said above, what you are referring to isn't the multitasking I'm talking about. I'm talking about having fully separate applications on the screen at the same time. Not just there being a video embedded somewhere in the interface. Having videos embedded in the UI doesn't even necessarily require true concurrency.
I'd need more information about both of these topics in order to give more insight.
The reason the PS3 OS is lacking in chat features isn't because it is too difficult to implement. It's because there isn't enough RAM. Switching over to a web app would actually make that problem worse, since web apps use far more RAM than native ones.
Similar reasoning applies to the rest of the OS. Sure, they would have the features to reimplement the XMB in HTML/JS, but it would be much slower than the current version, and would use a lot more RAM.
Also, just because you can rewrite an app doesn't mean that you should. That is a terrible reason to rewrite something. It's only worth it if there are significant advantages to doing it, which there really wouldn't be in this case. "It is easier to write the apps in HTML/JS, than as native apps" is not a significant enough benefit when you already have a competently written, working native implementation.
1) Nearly all native programs necessary to support a browser as well as the Javascript engine are loaded as part of the kernel.
2) Every application uses those same program APIs that the browser uses and they can be called from C++, Lua, Javascript, Java, Mono and more.
3) Apps for the browser desktop can be C++ or signed third party WebMAF apps.
Everything runs under a framework (desktop) that has support for a browser. All W3C extensions for a browser are the creation of APIs in native programs that can be called by a browser's Javascript engine in a STANDARD published by W3C. C++ programs can call those same APIs.
The advantages are numerous; reuse of the same code, common APIs used by every app, smaller kernel always loaded which usually results in faster APP loads including the browser. When I say the Vidipath platforms have W3C extensions like Java and DLNA I mean that the platform has to have Java and DLNA as native programs that have APIs that can be called by EVERY app no matter what it's execution engine; C++, Mono, Lua, Javascipt etc. For W3C WebRTC support there are native language programs supporting W3C standard APIs for the system Camera, Video processing and audio as well as audio echo-cancellation.
All or most of the Stability updates are rewrites to the Native libraries to support new APIs but still using those same native libraries. We may not see new features being supported but the "hooks" for the new features are there. When a new GTKwebkit API is developed and added as a Javascript feature supported by Webkit it's really a native language program being used by a scripting language (Javascript) and that same native program can be used by Lua or Mono or Java but sometimes changes need to be made to the native program to support a new API (call/feature).
HTML5 <video> is a native language program supporting a number of video features (APIs) that are reused and reused and reused by nearly everything. This includes extensions (APIs) for DRM, DASH and more. HTML5 <video> routines are now used by DLNA and require DASH, are used by Video Chat and require DASH, will be used by the 4K blu-ray digital bridge which requires the use of the MSE DRM extensions which Playready and Playready ND will hook into.
If a video chat app uses the HTML5 <video> routines it would result in a much much smaller app. As an example, Netflix on the PS3 is a stand alone app and includes DRM, Player, Javascript engine, video framework and native libraries which take about 37 megs (more when in memory). If it was implemented in a browser it would require -0- space beyond the bookmark and Icon. As a WebMAF app, you still need the MAF framework but are using the system browser libraries so about 10 MB (guess).
Audio chat takes even less memory but it could not be included in game on the PS3 either (this was discussed with the release of PS3 firmware 3.0) either because there was limited memory or some games from EA didn't follow Sony recommendations and those games would break if Sony implemented Video chat as part of the OS including "Pulse Audio" routines which were then recently implemented for Gnome audio APIs.
The original PS3 OS native language libraries did not have the APIs it now has and the early versions created apps like chat that were mostly stand alone with very little reuse of common native libraries. A XMB rewrite COULD result in a smaller kernel and faster loads at the same time. The PS3 is getting a rewrite to support Playready because Sony wants the PS3 to support Vidipath. Vidipath will require many new features that require the use of MODERN browser native libraries. IF you have them loaded then why would you still use apps that are primarily stand alone like Chat when you can create a C++ version that is extremely small using the native libraries already loaded for Vidipath features and at the same time update to use a common: "Friend/Contact", Calendar, notebook, event log....
There is a common reason Gnome supports a video editor and the PS3 and PS4 support a video editor...it's a nice feature but the real reason is the HTML5 <video> native library has APIs that make creating a basic video editor extremely easy.
To clear up previous questions; the GTKwebkit project creates APIs for features that need to be supported by Apple or Google changes in webkit. The APIs use native libraries typically found on Gnome Linux builds which may need rewrites to support those APIs. Sony duplicates those same features/APIs using BSD native libraries. Since Webkit is supported across multiple OS there are native libraries Sony can use on BSD. Sony makes minor changes to the Vector graphic routines for browser chrome but uses the GTK APIs without change.