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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx]On Behalf Of >Vlad.Stirbu@xxxxxxxxx >Sent: Tuesday, July 05, 2005 1:31 PM >To: saravanants@xxxxxxxxxxxxxxx; ietf@xxxxxxxx; remoteui@xxxxxxxx >Subject: RE: Remote UI BoF at IETF63 > > >Hi, > >> -----Original Message----- >> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx]On >Behalf Of >> ext saravanan t s >> Sent: 04 July, 2005 18:06 >> To: ietf@xxxxxxxx; remoteui@xxxxxxxx >> 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@xxxxxxxx >https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf