Hi Vlad & others
Just adding some opinions on this from my side, since I found this idea
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?
Saravanan T S
[mailto:ietf-bounces(_at_)ietf(_dot_)org]On Behalf Of
Sent: Friday, July 01, 2005 5:05 PM
To: ietf(_at_)ietf(_dot_)org; remoteui(_at_)ietf(_dot_)org
Subject: Re: Remote UI BoF at IETF63
3. Why this cannot be done with existing protocol?
Existing protocols can be split in two categories:
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
interface (GDI), such as DrawLine(), DrawString(), etc. are
copied across the
network. The client is responsible for interpreting these
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
protocols where the drawing commands are restricted to
The problem with these approaches is that, in order to
render the UI, the
clients are following blindly the instructions received from
they don't have means to influence the appearance of the UI,
render the UI using the graphical elements/instructions that
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.
Ietf mailing list
Ietf mailing list