Hi Vlad & others Just adding some opinions on this from my side, since I found this idea interesting: 1. Even though today's clients are powerful enough to handle the widgets and adaptation, maybe on the server side, certain computations and algos could be clubbed to reduce the load on the pda's and other devices. The extra resources (maybe read "power") on the pda's and other devices could be used for adding additional features (or maybe extending battery life?) 2. How many look and feel "standards" or maybe "UI Languages" the server can support? Does this imply that there will be only a limited set of L&F that can be supported by the server and rendered on the client? Will this be a limitation for different devices (talking of embedded) having different levels of needs on widgets (qualitatively: very simple to quite complex)? 3. On the other hand, there may be one more advantage to have clients send the description of the L&F sent to the server & server managing the client based on its description - is it possible that the bandwidth will be used more efficiently than the existing protocols that seem to achieve similar purposes for the end user? Regards, Saravanan T S >-----Original Message----- >From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx]On Behalf Of >David Hopwood >Sent: Friday, July 01, 2005 5:05 PM >To: ietf@xxxxxxxx; remoteui@xxxxxxxx >Subject: Re: Remote UI BoF at IETF63 > > >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 mailing list >Ietf@xxxxxxxx >https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf