Subject: RE: Remote UI BoF at IETF63

From: [email-masked]
Date: Tue, 5 Jul 2005 11:01:07 +0300

Hi,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext saravanan t s
> Sent: 04 July, 2005 18:06
> To: [email-masked]; [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: saravanan t s <[email-masked]>
Date: Tue, 05 Jul 2005 19:45:42 +0530

Hi Vlad,

  Thanks for the reply.
  I will now go through the draft for a better understanding.

Regards,
Saravanan T S

>[email-masked]
>Sent: Tuesday, July 05, 2005 1:31 PM
>To: [email-masked]; [email-masked]; [email-masked]
>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).
>
>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.
>
>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
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 05 Jul 2005 08:32:09 -0700

> 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.

on the other hand, having all the semantics on the server means that there 
will be a higher interaction rate with the server.  More network traffic and 
therefore the client will be doing more network i/o.

that takes power.

> I think that by sending widget description over the wire you already use 
 > the bandwidth more efficiently than existing protocols (i.e.
 > ramebuffer-level or graphics-level) which tend to send more
 > "screen captures" that in the end eats more bandwidth.

right.

-- 
 
   d/

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net