RE: Binary upload API Was: Options for compound entries

["Micone, Andrew (Manpower Contract)" <andrew.micone@xxxxxx>]

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.

  _____  

Andy Micone
Performance Engineer / Process Lead 
Performance R&D
(208) 396-4228 
andrew.micone@xxxxxx

 



-----Original Message-----
From: owner-atom-syntax@xxxxxxxxxxxx [mailto:owner-atom-syntax@xxxxxxxxxxxx] On Behalf Of John Panzer
Sent: Thursday, April 29, 2004 3:35 PM
To: Robert Sayre
Cc: Bill de hÓra; Tim Bray; Janne Jalkanen; 'Atom Syntax'
Subject: Re: Binary upload API Was: Options for compound entries





Robert Sayre wrote on 4/29/2004, 1:43 PM:

 >
 > Quoting Bill de hÓra <bill@xxxxxxxxxx>:
 >
 > > John Panzer wrote:
 > >
 > > > I gotta say I'm confused by this statement.  Base64 AFAIK involves  > a 33%  > > > space overhead, therefore at least a 33% time overhead, for the  > portion  > > > of the data that is binary.  I'm trying to imagine an Atom client  > that  > > > (a) is dealing with large binaries, so this overhead matters at  > all, and  > > > (b) can't accept this amount of overhead.  Hmmm.... maybe a  > wristwatch  > > > spy cam?  :^) Or maybe I'm wrong and the overhead is a lot more than  > > > that?  Could someone who finds Base64's overhead unacceptable list  > some  > > > use cases and some numbers?  I think it would be enlightening, at  > least  > > > for me.  > >  > > So would I. Unless someone has numbers to back up the claims, the  > > double declaration (encoding+mimetype) style seems fine.  > >  >  > Quoting Janne Jalkanen <Janne.Jalkanen@xxxxxxxxx>:  > > >Does everyone feel that Base64 efficient enough for uploading  > > >movies/images?  > > It adds what, 33%, to any binary size?  > >  > > So yeah, if you are paying for a mobile connection per Megabyte (like  > > most GPRS connections are), it's gonna be hurting the users a lot. It's  > > not really an optimal solution, except for really small sizes.  >  > I guess my summary should have included the quote above. Full message:  >  > http://www.imc.org/atom-syntax/mail-archive/msg03560.html
 >
 > Robert Sayre

Hmm...  As a data point, in my area (OK, Silicon Valley) T-Mobile and 
Cingular Wireless offer "unlimited" GPRS data plans for <$20/month. 
(Though you can't necessarily find this on their websites -- I love 
phone companies.)  Cingular just added this ability.  Is this an 
anomaly?  Just wondering if this is an edge case that could be handled 
in some other way.

(For example, provide for a binary extension -- restricted only to HTTP 
uploads -- and allow clients to query for the capability.  Most clients 
won't care, some mobile clients might implement this.  If Atom is 
proxy-able, people could perhaps even build Atom proxy servers that 
implement the binary extension and translate to the Base64 'accepted 
everywhere' standard.)