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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf