Hi David,
Framebuffer-level protocols can be viewed as a special case
of graphics-level
protocols where the drawing commands are restricted to
bitblt-like commands.
Yes, it is possible to have a graphics-level protocol with a restricted
functionality that is matching that of framebuffer-level protocol but the
overhead and the software and hardware complexity required are to high.
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.
Yes, you are right. For some simple devices you can do the customisation on the
server side in order to reduce the complexity, but in that case it is probably
best to use a framebuffer-level protocol rather than a widget-level one; these
simple clients typically don't have a windowing system/widget set anyway.
The work proposed here is for advanced client devices that have their own
windowing system and their own widget sets, i.e. desktop, laptop or tablet
computers, PDAs or mobile phones. These devices have enough resources and the
means to do the scaling and adaptation by themselves.
Vlad
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf