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.
3) Apps for the browser desktop can be C++ or signed third party WebMAF apps.
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.
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.
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.