The reference article on this subject is definitively this one from Tim Anderson's ITWriting blog.
In fact, a
spawns a new process in the WinRT space which is an actual
WinRT LiveTile application.
This WinRT app communicates with the VCL-Metropolis "desktop" backend via REST to start/stop the application or update the LiveTile.
So, for the user point of view, it will behave like a native WinRT application.
End-users, explains Thomas, will not care about the WinRT or Win32 technology, but only notice that some apps have the new style and some do not. “We took the VCL and FireMonkey frameworks and used the styling engines that we introduced in XE2 to allow them to modify the forms to take on the look of those controls, as well as adding features like Windows 8 gesture support, improving the touch handling, and also taking on some of the standard templates like the grid and split views.”
Metropolis also support Live Tiles with update of dynamic content, and even enables apps to show up in the Windows 8 App Bar (which most desktop application do not support). This is done by means of a small WinRT app that is installed with the Metropolis application, and which communicates with it over a REST API – there being no built-in inter-process communication between desktop and WinRT apps. The WinRT app is a kind of proxy that lets the user launch or close the desktop Metropolis app. However access to Windows 8 contracts is not supported. “I think we’re hitting on the key elements that end users are going to expect when they’re working with WinRT applications,” says Thomas.
(quoted from Tim's article)
I suspect the REST API is based on DataSnap.
This is a Client-Server stateless approach for User Interface synchronization, just like what we use in mORMot since years.
There are still some potential installation issues.
So-called "sideloading" works with some tweaks during installation process of the application.
Two drawbacks may arise:
1. The Windows security policy may change, and the tweak may be broken from any future Security Update pack;
2. Sounds like if, for security reasons, system may require enterprise SKUs (or a Domain Controler) - so it may not work for my grand mother home PC.
As a temporary conclusion, sounds like if WinRT support in XE3 is not as minimal as expected. There is more than a new VCL style named "Metropolis" bounded. End-user may be faked by the application behavior - I've seen FireMonkey / DXScene forms be much more reactive than WPF applications, on the same hardware (just flip a window in both frameworks, and you may be amazed).
and lighter than such a complex and over-plumbing approach. I think
easily support WinRT as target, in addition to mobile or desktop
browsers: code in Object Pascal, talk to a mORMot server via REST, and
I hope that Jon Lennart recent accident won't delay their project too much.
Jon, we wish you a quick recovery, and being back as soon as possible to your family and your great coding!
Feedback is welcome on our forum.