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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf