Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Sep 8, 2014, at 1:33 PM, Ian Hickson i...@hixie.ch wrote: I got some feedback on my last e-mail to the effect that having the proposal sandwiched between the rationale and the examples of how it would be used made it hard to find, so I'm reproducing the proposal here (slightly updated based on feedback): --- These loadable elements: script, link, style, video, img, object, iframe, audio ...get the following new attributes: needs= Gives a list of IDs of other elements that this one needs, known as The Dependencies. Each dependency is added to this element's [[Dependencies]] in the ES6 loader. loadpolicy= The load policy. Consists of a space-separated set of keywords, of which one may be from the following list: block, async, optimistic, when-needed, late-run, declare. The other allowed keywords are precache, low-priority, and force. (Maybe we disallow block and force since they're for legacy only.) Different elements have different defaults. precache isn't allowed if the keywords block or async are specified, since those always load immediately. The keywords' meanings are as follows: block - stop parsing until this resource is applied async - fetch now, apply asap optimistic - fetch when needed, apply asap when-needed - fetch when needed, apply when needed declare - fetch when needed, don't apply precache - for fetch with needed, consider fetching earlier low-priority - let other things go first force - always fetch anew, don't de-dupe I haven't discussed in detail with my colleagues but my impression is that we're quite concerned about the number of load policy options and the complexity they introduce. I'm not certain if there is a value in having a load policy for fetch when needed since that could be achieved by inserting an script/style/etc... element when needed. Are there any use cases for having script/style/etc... elements that before they start fetching respective sub resources? It also appears that apply when needed can also be achieved by inserting link[rel=preload] first and later inserting an element of the appreciate type since the resource would have been cached by the browser at that point in practice. If we wanted to make that explicit, we could add a method like loadFromPreload to script and syle elements and have it take link[rel=reload]. These two changes should dramatically reduce the number of load policies we need. - R. Niwa
[whatwg] (no subject)
On 9/12/14, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: What I'd you're a long way away from any medical help? What? In my mind this is part of the larger drive of the web of things (IoT applied to the web) and needs device APIs. This might not be the right group to discuss it in though. Where is the best place to define the APIs for devices to track, monitor, and surveil us? Perhaps the W3C is the best place. It is funded by the very corporations that are making such monitoring devices and with developer relations experts to tell you how. These corporations are backed by philanthropists, such as William Gates III, whose opposes climate change, whistleblowers, and overpopulation. Sure, Microsoft might've backdoored stuff for the NSA for the past 10 years, and Apple might share your info to the NSA (they'll get it anyway). And Google and the CIA might want info for MindMeld (TM) or Recorded Future, which they openly fund (links below). He who pays the piper calls the tune. You don't have anything to hide, right? Or maybe the question of how or where to best to engineer this or that new gadget is best answered by first asking how to prevent such engineering from being used by a top-down, efficient system. The system is working. That is the problem. http://www.rawstory.com/rs/2014/09/10/cant-wait-for-the-apple-watch-beware-your-fitness-data-may-be-sold-or-used-against-you/ http://rt.com/usa/microsoft-nsa-snowden-leak-971/ Google CIA funded MindMeld https://en.wikipedia.org/wiki/Recorded_Future CIA funded MindMeld http://techcrunch.com/2014/07/17/expect-labs-lands-in-q-tel-investment-will-help-u-s-intelligence-integrate-its-mindmeld-technology/ --
Re: [whatwg] (no subject)
On Sun, Sep 14, 2014 at 12:17 PM, javascr...@riseup.net wrote: On 9/12/14, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: What I'd you're a long way away from any medical help? What? s/I'd/if/ (sorry - mobile keyboard) In my mind this is part of the larger drive of the web of things (IoT applied to the web) and needs device APIs. This might not be the right group to discuss it in though. Where is the best place to define the APIs for devices to track, monitor, and surveil us? Perhaps the W3C is the best place. It is funded by the very corporations that are making such monitoring devices and with developer relations experts to tell you how. These corporations are backed by philanthropists, such as William Gates III, whose opposes climate change, whistleblowers, and overpopulation. Sure, Microsoft might've backdoored stuff for the NSA for the past 10 years, and Apple might share your info to the NSA (they'll get it anyway). And Google and the CIA might want info for MindMeld (TM) or Recorded Future, which they openly fund (links below). He who pays the piper calls the tune. You don't have anything to hide, right? Or maybe the question of how or where to best to engineer this or that new gadget is best answered by first asking how to prevent such engineering from being used by a top-down, efficient system. The system is working. That is the problem. http://www.rawstory.com/rs/2014/09/10/cant-wait-for-the-apple-watch-beware-your-fitness-data-may-be-sold-or-used-against-you/ http://rt.com/usa/microsoft-nsa-snowden-leak-971/ Google CIA funded MindMeld https://en.wikipedia.org/wiki/Recorded_Future CIA funded MindMeld http://techcrunch.com/2014/07/17/expect-labs-lands-in-q-tel-investment-will-help-u-s-intelligence-integrate-its-mindmeld-technology/ If you don't want to give your data to anyone, don't. Nobody is forcing you to share your medical data over the Internet. I don't see that stopping the world moving forward though. Given that it is happening anyway, I'd rather go with an open API than proprietary ones where we don't know what is happening. Silvia.
