Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore
Hi Adam, On 10.5.2012, at 14.20, ext Anssi Kostiainen wrote: On 9.5.2012, at 23.22, ext Adam Barth wrote: Thanks. I just have two pieces of feedback: 1) As far as I know, we don't have any plans to implement the WebIDL interfaces. 2) From the spec, it sounds like the capture attribute is limited to only known values (see http://www.whatwg.org/specs/web-apps/current-work/#limited-to-only-known-values), but it would be good to say that explicitly and link to HTML5 to provide the definition. Thanks Adam. We'll continue this spec related discussion on the public-device-a...@w3.org mailing list: http://lists.w3.org/Archives/Public/public-device-apis/ A new W3C Working Draft snapshot of the spec was published couple of days ago: http://www.w3.org/TR/html-media-capture/ (The latest editor's draft, current identical with the snapshot, is at: http://dev.w3.org/2009/dap/camera/) The aim was to align the spec with implementations. Most of the spec was rewritten to match the HTML terminology, the Web IDL interfaces of no interest were dropped, and invalid value dafault and missing value default were defined. It is a short spec, so should not take long to review. Any feedback is appreciated. -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore
On 9.5.2012, at 23.22, ext Adam Barth wrote: Thanks. I just have two pieces of feedback: 1) As far as I know, we don't have any plans to implement the WebIDL interfaces. 2) From the spec, it sounds like the capture attribute is limited to only known values (see http://www.whatwg.org/specs/web-apps/current-work/#limited-to-only-known-values), but it would be good to say that explicitly and link to HTML5 to provide the definition. Thanks Adam. We'll continue this spec related discussion on the public-device-a...@w3.org mailing list: http://lists.w3.org/Archives/Public/public-device-apis/ -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore
Hi Tamura, Adam, On 9.5.2012, at 11.44, ext TAMURA, Kent wrote: I wonder if the standardization is active. Even the editor's draft has not been updated for one year. Good that you ask -- the spec has been waiting for implementors' feedback :) If you're able to send us feedback based on your implementation experience, I'm happy to pick up the spec, bake in your feedback, and push it forward on the standards track (the current spec editors have moved on to do other things). The feedback should be sent to the public-device-a...@w3.org mailing list, see: http://lists.w3.org/Archives/Public/public-device-apis/ The latest editor's draft is at: http://dev.w3.org/2009/dap/camera/ Any feedback is welcome. E.g. given that no one seems to be interested in implementing the MediaFile* interfaces, we should probably consider dropping them from the spec. Currently we have two open issues in the spec issue tracker (http://www.w3.org/2009/dap/track/products/25), and some other issues highlighted in the spec itself. Cheers, -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: On 15.6.2011, at 21.29, ext Darin Fisher wrote: There should probably be a way to poll the current state. Much as you can poll the document.readyState and respond to progress events, it would seem to make sense to have a way to poll the battery state as well as respond to battery state change events. The current design is quite similar to that of the Device Orientation Event. We discussed the polling option but settled on the current design. Let me know if you'd like me to dig into archives for some pointers on that design decision. I'd be curious to read them. Off-hand it seems like device orientation suffers from the same problem. You wouldn't want the application to do too much work that would be discarded once it finds out that the orientation is X instead of Y. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] It seems like this is information that we have available immediately, and it is a bit unfortunate that page authors need to delay initialization until they receive the initial orientation or battery status event. In addition to the above mentioned reason, a synchronous API might encourage web authors to write badly performing code, i.e. poll the battery status via setInterval() too often. In the current event-driven design a new event is dispatched only when the battery status changes. -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Hi, On 15.6.2011, at 20.25, ext Greg Simon wrote: From what I can tell the spec offers no way for the web application to initialize any algorithm based on the battery/power state because there is no guarantee of minimum time when a new document is created and the first battery event arrives. Ideally there would be a way to kick the UA into sending the battery event on demand. To keep the minimum time as small as possible, the first BatteryStatusEvent should be fed into an appropriate task queue upon event listener registration. An excerpt from the spec: [[ When an event listener is registered with the event type batterystatus, then the User Agent must retrieve the relevant information and dispatch a BatteryStatusEvent event asynchronously as defined in [DOM-LEVEL-3-EVENTS]. ]] The relevant section in the D3E spec would be: http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#sync-async Otherwise the web application starts at full-throttle (burning battery) on a device with 10% battery left until it *drains* enough to get a batteryEvent. I agree we'll need to handle that case, and that's why the above-mentioned requirement is in the spec. On 15.6.2011, at 21.29, ext Darin Fisher wrote: There should probably be a way to poll the current state. Much as you can poll the document.readyState and respond to progress events, it would seem to make sense to have a way to poll the battery state as well as respond to battery state change events. The current design is quite similar to that of the Device Orientation Event. We discussed the polling option but settled on the current design. Let me know if you'd like me to dig into archives for some pointers on that design decision. -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Hi, On 15.6.2011, at 17.24, ext Ryosuke Niwa wrote: 2011/6/15 권기홍 kihong.k...@samsung.com I wanted to let you know that I plan to add battery status event support to WebCore. The Battery Status Event is a new feature that is defined by W3C (http://www.w3.org/TR/battery-status) It seems like the working draft has a couple of TODOs now. Is the spec sufficiently stable? Are other browser vendors implementing this feature? As noted by Kihong, the latest draft addresses the TODOs: http://dev.w3.org/2009/dap/system-info/battery-status.html The W3C Device APIs Working Group intends to hit Last Call i.e. stable draft with the above version at the end of this month. On 15.6.2011, at 12.41, ext Holger Freyther wrote: I am not participating in any W3C group so this might or might have been discussed but this specification seems to be over simplified, specially if you compare it what is provided by the power supply class of the Linux kernel[1]. The topic was, indeed, discussed in the group. We tried a more complex approach, but it did not fly. I can give you some pointers off the list if you're interested in delving into that. What happens if you have more than one battery? Many modern devices have backup batteries, e.g. to keep the RTC. What is the upgrade path for this event to support applications that want to have a more detailed view (e.g. a dashboard in a server farm that also wants to query the UPS)? The spec is intentionally designed to abstract away such details. A typical web app developer should not be concerned about the complexities of multiple batteries a device may have. Further spec specific feedback is welcome, preferably to public-device-apis ML: http://lists.w3.org/Archives/Public/public-device-apis/ -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
