- From: timeless <timeless@gmail.com>
- Date: Sun, 27 Jan 2008 22:52:25 +0200
On Jan 25, 2008 2:48 PM, Mikko Rantalainen <mikko.rantalainen at peda.net> wrote:
> It's wise to always trying to minimize the battery usage in a battery
> operated device. However, if the device is already using wireless or
> wired communication for transmitting the data set it cannot just do
> "nothing".
from my unfortunate experience in this area, timers cost extra. (even
above wifi cost.)
> Notice, also, that I wasn't suggesting that the above text is
> a "MUST" but instead just "SHOULD". Perhaps it could be even "recommended".
that's better :)
> How can the "file picker posting system" know something like actual
> bandwidth beforehand? Perhaps the user is using a mobile device that is
> currently on WLAN connection (say 54mbps) and the user starts sending
> the file. If the file picker has told the user that sending takes
> approximately 5 minutes for the selected file, how is the user supposed
> to know the actual sending time after he starts moving and the
> connection drops to 3G mobile network (around 0.5mbps) or GPRS or GSM
> data mobile network (around 0.001mbps).
i think we're supposed to send offline notifications, i'd assume that
network changes would trigger that.
whether they do or don't, your ip address will change (unless you have
a really magical vpn), and as such your connection will fail. without
some magical resume features (perhaps as i described below), you'll
have to start over. so no problem here.
> I cannot imagine anything but a
> progress bar displaying the current rate (or transfer rate for the
> previous 30 seconds if that's how often the progress can be updated
> because the battery must be conserved).
>
> > http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
> > lists a fileSize property. I think it'd be nice if gmail could tell me
> > that "this file will take an hour to upload". I also wonder if it'd be
> > a good idea to support getting chunks of a file, because if I had a
> > 4gb file, using DOMFile().getAsBinary() would probably crash my
> > browser. I'd kinda like for gmail to be able to do partial uploads....
> > In order for this to work, there should be DOMString hash() which has
> > an optional argument for a hash algorithm ("md5sum", a const for
> > md5sum, or maybe an object { processBlock:function(data) {},
> > getHash:function() }. Otherwise a user could try feeding sequential
> > blocks from different files.
> I agree that something like that would be nice to have for some cases.
> However, I do not think that such behavior would make upload progress
> monitoring unneeded.
> The current "fix" for this problem is to connect
> the receiving server with HttpXmlRequest() and ask the server how much
> data the server has received. Then this result can be displayed somehow
> to the user.
implementation demos are probably a good thing before discussing a standard :)
> I don't think that IE has a working upload progress meter. I have always
> experienced IE just to simply slowly increase the progress meter until
> the page is done; it's advancing even if I disconnect the network cable
> during the progress... (just tried IE6 and IE7)
interesting (clever even)
> If it will probably be added in the future anyway shouldn't the spec
> recommend doing so sooner?
spec after implementation experience, not before. preferably including
experience with mobile devices.
> I'm not saying that every UA MUST do so but
> they should (unless they have a good reason not to).
Received on Sunday, 27 January 2008 12:52:25 UTC