Hi Vlad,
Thanks for the reply.
I will now go through the draft for a better understanding.
Regards,
Saravanan T S
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org]On Behalf Of
Vlad(_dot_)Stirbu(_at_)nokia(_dot_)com
Sent: Tuesday, July 05, 2005 1:31 PM
To: saravanants(_at_)tataelxsi(_dot_)co(_dot_)in; ietf(_at_)ietf(_dot_)org;
remoteui(_at_)ietf(_dot_)org
Subject: RE: Remote UI BoF at IETF63
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf