Vlad.Stirbu@xxxxxxxxx wrote:
3. Why this cannot be done with existing protocol? Existing protocols can be split in two categories: framebuffer-level and graphics-level protocols. In the framebuffer-level protocol, the contents of the framebuffer (i.e. the individual pixels) are copied across the network to a framebuffer on the client. In order to avoid sending the full screen every time something changed on the screen, these protocols typically send only the pixels that are changed inside the clipping regions to the client. Examples of such protocols are VNC and protocols based on T.120, like Microsoft's RDP. In the graphics-level protocol, the drawing request to the graphical device interface (GDI), such as DrawLine(), DrawString(), etc. are copied across the network. The client is responsible for interpreting these commands and rendering the lines, rectangles, strings, etc. in its framebuffer. Example of such protocol is X Windows.
Framebuffer-level protocols can be viewed as a special case of graphics-level protocols where the drawing commands are restricted to bitblt-like commands.
The problem with these approaches is that, in order to render the UI, the clients are following blindly the instructions received from the server; they don't have means to influence the appearance of the UI, they just render the UI using the graphical elements/instructions that are provided by the server and are specific to the server platform.
Having the UI adapt to a look-and-feel appropriate to the client device (and user's preferences) doesn't automatically imply that it has to be the client that does this adaptation. The client could send the server a description of the preferred L&F. The advantage of this is that it allows clients to be much simpler, putting the complexity on the server which is likely to have more memory, processing power, etc. -- David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf