- From: Scott Lawrence <slawrence@virata.com>
- Date: Tue, 17 Apr 2001 13:49:15 -0400
- To: discuss@apps.ietf.org
Dave Crocker wrote: > At 04:54 PM 4/16/2001, ned.freed@mrochek.com wrote: > >> A better approach would be to use BEEP's multiple >> session capability -- the client could send the control document over >> and the >> server could request things from the client on a different channel. >> The result >> is a single connection, just in time data delivery, and no need for >> the client >> to have to try and predict when the server will need something. The >> disadvantage is that it's a new protocol, but frankly, if this problem >> is worth >> solving we should not be afraid of a new protocol to solve it. > > > I like this description quite a lot. > > It also sounds like exactly the same task that a Web client has when > rendering a web page... I agree (as I did in person in Minneapolis) with Ned that the fundamental problem is that of just-in-time delivery, and the sender cannot know what that means. For example, in looking at our server logs, we do not find that browsers all request the images for a given HTML document in the same order. These drafts were motivated by the buffering problems of an IPP printer, but similar problems would be faced by any device that must combine mulitple components to produce a whole (wireless PDA displaying an alert with a specific font and a graphic). Far better is to provide a means of doing bidirectional requests. IPP already incorporates print-by-reference, so having the sender incorporate references to objects it is prepared to provide through a special-purpose HTTP server is not much of a stretch - putting the sequencing control of them into the renderer where it belongs. The HTTP Upgrade mechanism could be used to switch the HTTP/IPP connection to BEEP/xxx for any value of xxx (including HTTP, even if that would give people alergic reactions). -- Scott Lawrence Architect slawrence@virata.com Virata Embedded Web Technology http://www.emweb.com/
Received on Tuesday, 17 April 2001 13:50:06 UTC