RE: Binary upload API Was: Options for compound entries

["John Panzer" <jpanzer@xxxxxxx>]

Micone, Andrew (Manpower Contract) wrote on 4/30/2004, 12:44 PM:

 >
 > Keep in mind that what is desirable for the consumer isn't necessarily
 > desirable for the producer or service provider. That 33% overhead from
 > encoding has a real cost associated with it. Multiplied over many
 > mobile devices in a service provider network the cost is substantial.
 > Remember, in general what subscribers pay for their bandwidth doesn't
 > reflect what it costs the provider. The bell curve says that the half
 > of the subscribers who have below average usage will more than pay for
 > those with above average usage. When something throws that out of
 > balance the service provider eats the bandwidth charges and looks for
 > ways to reduce bandwidth usage or passes costs onto the consumer. If
 > the cool new feature on the mobile device inflates bandwidth costs by
 > 33% for no good reason, that's the first place the provider is going
 > to look to improve, lock down, or cost out to the consumer.

Note that this is 33% of the image upload traffic, not of the total 
traffic to and from a device.  Compared to the total traffic, would it 
that big a deal?  (I don't know.)

More generally, is this something that could be dealt with via a 
standard extension, oriented specifically towards HTTP upload, as long 
as said service providers could provide appropriate gateway/proxy 
services?  The idea here being, the extension doesn't need to solve 
every performance problem, just this use case, and hence is more 
tractable; and not all servers and clients need to implement the 
extension in order for the use case to be addressed.  In this case, the 
extension is purely for cost/performance and wouldn't affect 
interoperability very much if at all.

-John Panzer