Hi,
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org]On Behalf Of
ext saravanan t s
Sent: 04 July, 2005 18:06
To: ietf(_at_)ietf(_dot_)org; remoteui(_at_)ietf(_dot_)org
Subject: RE: Remote UI BoF at IETF63
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?)
Talking about power saving, I think that the most important feature that we
have here is that the application logic is run entirely in the server side.
This thing will definitely save power and also will reduce the software
complexity of the client. If the client supports widgets natively it will use
them anyway to render the UI regardless the adaptation is done on the server
side or not.
Lets not forget that the servers also are not having unlimited resources and it
would be nice to use the resources where they are available (i.e. clients with
native widgets).
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)?
The protocol should be UI language independent and I believe that it will not
add "technical" constraints on the server side, those will be rather of
"business" nature.
From the protocol point of view the UI is just a collection of widgets. Now it
is up to the widgets to be very simple or 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?
I think that by sending widget description over the wire you already use the
bandwidth more efficiently than existing protocols (i.e. framebuffer-level or
graphics-level) which tend to send more "screen captures" that in the end eats
more bandwidth.
Even so, in the case of widget-level protocol, the client and server exchange
information about look and feel during the "session setup" step. Please have a
look at the proposed protocol draft here
http://www.ietf.org/internet-drafts/draft-stirbu-lrdp-00.txt.
Vlad
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf