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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org]On Behalf Of
David Hopwood
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
Vlad(_dot_)Stirbu(_at_)nokia(_dot_)com 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(_dot_)nospam(_dot_)hopwood(_at_)blueyonder(_dot_)co(_dot_)uk>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf