- From: Josh Soref <jsoref@rim.com>
- Date: Mon, 21 Jan 2013 22:22:23 +0000
- To: Core Mobile <public-coremob@w3.org>
Hidetoshi wrote: > Thanks for your comment and sharing your experience. :) > I also learned a new proverb ;-). :) > From your experience, it is not necessarily good for > the UA to be always greedy especially if the connection is charged, > which will lead to throttling or a bill shock. right > I also don't think it is a good idea to tell the UA about the > instantaneous bandwidth, which usually changes very often. More or less, maybe. > Coarser > information such as the connection type (WiFi/3G/LTE) will be more > useful (not always, as you say). Sometimes, or not. > Time-of-day or location (topography?) > could also be used, Sometimes, maybe. > but we should start with simpler and fewer parameters. Err, no. we should start with actual problems and work out something that UAs could usefully implement. A few details here. A. coremob is not a spec writing WG (please read the charter). B. coremob is able to provide UCs. 1. It's really probably best for everyone if the API ends up being "I would like to have this resource X retrieved eventually, preferably by deadline Y, tell me when it arrives". I'd like to know if this API works for all the actual UCs people have. But that means people need to gather them (B) instead of dreaming that they must exist. Lots of problems theoretically exist, but without real world surveys showing how often they're problems and what people would like to do with the information, there's no point in trying to spend time on solving them. Once that's done, someone could work with an addon system (Cordova is a possibility, but I'd rather it be a Mozilla extension) to demo a basic API such as I've described. Questions arise: C. Do people want: 1 resource X, 1 set of resources X1...X200, the ability to add/remove requested resources dynamically? D. Do people have a need to reprioritize (resource A is more important than resource X, but still not urgent)? E. Are people better off with support for JAR/ZIP? F. Are people better off with support for some Delta / patching stuff? G. Are people really just asking for a working version of App-Cache? (if so, well, that will happen first anyway, and then we shouldn't waste our time on any of this.) > I just thought we should more look into it along this line maybe in the > future or for the next version... I'm sure that once there's a spec which has some chance of being implemented CoreMob will gladly add it to its wishlist. Until then, there's work to be done.... --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Monday, 21 January 2013 22:22:52 UTC