[webkit-dev] Some questions about adobe air version webkit

[wang chyz]

1.  I compiled adobe air
webkit(http://download.macromedia.com/pub/opensource/webkit/webkit_dreamweavercs5_labs_01.zip)
on Windows, but it’s size reach to 10m, and Adobe compiled it to 4m,
can somebody give me any adives?
2.  It seems the webkit version on above address is used in dreamwave
and some funtions are missing . How to download other version of air
webkit on http://webkit_view:webkit_v...@stlab.adobe.com:8080
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Expected behavior of "scrolling" attribute for IFrame element

[Ojan Vafai]

On Mon, Jun 13, 2011 at 11:21 AM, Darin Adler  wrote:

> On Jun 13, 2011, at 11:05 AM, Ojan Vafai wrote:
> > On Mon, Jun 13, 2011 at 10:51 AM, Darin Adler  wrote:
> >> Even though we need to prevent find or autoscrolling from scrolling, it
> seems we must not prevent explicit programmatic scrolling. I’ll add a
> comment to the bug about this.
> >
> > overflow:hidden divs are used to implement custom scrollbars. While
> find-in-page breaking wouldn't be too bad, breaking autoscrolling on these
> sites would likely require us to rollback the change. Maybe we should expose
> an attribute or CSS property to allow controlling this to give sites a
> workaround?
>
> Could be.
>
> I guess at root this is a user interface problem. Scrolling something if
> there is no UI for scrolling back is a problem. Similarly, scrolling
> something into view that a developer thinks is invisible is a problem. I
> guess the browser does need some way to tell if the user can scroll back, so
> it can various forms of scrolling in those cases.
>
> It would be best if we could correctly do this even on existing sites, but
> I don’t have any ideas about how to tell cases where a scroll would be a bad
> idea from cases where a scroll would be OK.
>

I agree. I think it would be fine to disable autoscroll for overflow:hidden
by default if we give a way for sites to turn it back on.

Implementing custom scrollbars is often a bad idea for websites that want to
> work well on platforms like Mac OS X Lion with a modern input device and iOS
> that don’t have conventional scrollbars. Not sure how to promulgate the best
> practices here.
>

Yeah. I can't think of a way to improve the situation beyond just giving
developers control over autoscroll.

Just curious: On the sites you know of that do this to implement custom
> scrollbars, do they use the scroll event to update the scrollbars when
> scrolling is done by the browser engine?
>

I'm not sure. The only real-world case of this I can think of is Google
Wave. I'm not sure what their implementation is like though.


>-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[Adam Crabtree]

If possible, I would encourage any breaking update to WebSockets (protocol
or JS API) to be feature detectable. Additionally, I would encourage WebKit
to postpone updating to -09 to coincide with expected changes to the JS API,
which may provide the necessary feature detection mechanisms (e.g.,
WebSocket.open a la XHR):
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102.


More specifically,  I work at HP Palm and our devices currently support the
-00 implementation of WebSockets, and while we are able to auto-update,
users must approvebut may not have been updated, and while as far as I
understand being just a protocol -00 could be detected and supported
server-side along-side -09, -00 implementations connecting to a -09 server
will have to fail (full RTT) in order to feature detect support for -09.


Allowing this feature detection along-side the protocol-break would enable
libraries and implementations to know what protocol versions are supported
and adjust behavior accordingly.


Alternatively, being that the protocol updates are in draft while API
updates are not with no anticipation of when they will be, some other means
of feature detection could be exposed instead.


Cheers,

Adam Crabtree
___
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

[Ryosuke Niwa]

On Wed, Jun 15, 2011 at 11:29 AM, 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.


I agree.  I'm rather surprised by the fact the current draft doesn't provide
any API for that.

- Ryosuke
___
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

[Darin Fisher]

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.

-Darin


On Wed, Jun 15, 2011 at 10:25 AM, 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.
>
> 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.
>
>
>
>
> On Wed, Jun 15, 2011 at 10:08 AM, Alexis Menard <
> alexis.men...@openbossa.org> wrote:
>
>> On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu 
>> wrote:
>> > On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson 
>> wrote:
>> >> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther 
>> wrote:
>> >>> On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
>>  Hi,
>> 
>> >>>
>> 
>>  The use-case for us is to enable content developers to implement
>> rudimentary power management (e.g. to stop "expensive" operations on the
>> page, perhaps save state). I'm not sure if this API is really meant for
>> accurately reporting all the possible power management states of the system
>> as Anssi pointed out.
>> >>>
>> >>> Okay, point on complexity taken. My question is what if you want to
>> add
>> >>> complexity, is there something in the event that prevents that (I have
>> no idea
>> >>> about DOM compatibility issues)? Don't get me wrong I think having
>> more device
>> >>> support is great.
>> >>>
>> >>> My other complain was, it is too simple. E.g. 'isPlugged' has no
>> guarantee
>> >>> that the battery is getting charged. Is this a problem?
>> >>
>> >> Why would a web page care about whether the battery is being charged
>> >> when the device is plugged in?
>> >>
>> >
>> > Because it would know not to start doing things that drain the
>> > battery. For instance, powering up a 3G antenna to download your
>> > latest emails could be annoying to users if the battery level is too
>> > low. 3G takes quite a bit of power and the device would be in danger
>> > of powering down.
>>
>> But if the phone is plugged in it can't power down. Most of modern
>> phones don't switch off anymore even if you have the battery low and
>> you play games, surf WiFi, go 3G as soon as you plugged it in. What
>> Brett meant is that it's useless to know that the battery is charging
>> while the phone is plugged in, you just want to know that it will not
>> switch off in any case so you can do whatever you want.
>>
>> >
>> > Thanks,
>> > Andrei
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>>
>>
>>
>> --
>> Alexis Menard
>> Software Engineer
>> INdT Recife Brazil
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
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

[Greg Simon]

>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.

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.




On Wed, Jun 15, 2011 at 10:08 AM, Alexis Menard  wrote:

> On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu 
> wrote:
> > On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson 
> wrote:
> >> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther 
> wrote:
> >>> On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
>  Hi,
> 
> >>>
> 
>  The use-case for us is to enable content developers to implement
> rudimentary power management (e.g. to stop "expensive" operations on the
> page, perhaps save state). I'm not sure if this API is really meant for
> accurately reporting all the possible power management states of the system
> as Anssi pointed out.
> >>>
> >>> Okay, point on complexity taken. My question is what if you want to add
> >>> complexity, is there something in the event that prevents that (I have
> no idea
> >>> about DOM compatibility issues)? Don't get me wrong I think having more
> device
> >>> support is great.
> >>>
> >>> My other complain was, it is too simple. E.g. 'isPlugged' has no
> guarantee
> >>> that the battery is getting charged. Is this a problem?
> >>
> >> Why would a web page care about whether the battery is being charged
> >> when the device is plugged in?
> >>
> >
> > Because it would know not to start doing things that drain the
> > battery. For instance, powering up a 3G antenna to download your
> > latest emails could be annoying to users if the battery level is too
> > low. 3G takes quite a bit of power and the device would be in danger
> > of powering down.
>
> But if the phone is plugged in it can't power down. Most of modern
> phones don't switch off anymore even if you have the battery low and
> you play games, surf WiFi, go 3G as soon as you plugged it in. What
> Brett meant is that it's useless to know that the battery is charging
> while the phone is plugged in, you just want to know that it will not
> switch off in any case so you can do whatever you want.
>
> >
> > Thanks,
> > Andrei
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
>
>
>
> --
> Alexis Menard
> Software Engineer
> INdT Recife Brazil
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
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

[Andrei Popescu]

On Wed, Jun 15, 2011 at 6:08 PM, Alexis Menard
 wrote:
> On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu  wrote:
>> On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson  wrote:
>>> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther  wrote:
 On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
> Hi,
>

>
> The use-case for us is to enable content developers to implement 
> rudimentary power management (e.g. to stop "expensive" operations on the 
> page, perhaps save state). I'm not sure if this API is really meant for 
> accurately reporting all the possible power management states of the 
> system as Anssi pointed out.

 Okay, point on complexity taken. My question is what if you want to add
 complexity, is there something in the event that prevents that (I have no 
 idea
 about DOM compatibility issues)? Don't get me wrong I think having more 
 device
 support is great.

 My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee
 that the battery is getting charged. Is this a problem?
>>>
>>> Why would a web page care about whether the battery is being charged
>>> when the device is plugged in?
>>>
>>
>> Because it would know not to start doing things that drain the
>> battery. For instance, powering up a 3G antenna to download your
>> latest emails could be annoying to users if the battery level is too
>> low. 3G takes quite a bit of power and the device would be in danger
>> of powering down.
>
> But if the phone is plugged in it can't power down. Most of modern
> phones don't switch off anymore even if you have the battery low and
> you play games, surf WiFi, go 3G as soon as you plugged it in. What
> Brett meant is that it's useless to know that the battery is charging
> while the phone is plugged in, you just want to know that it will not
> switch off in any case so you can do whatever you want.
>

Ugh, you're right, I just misunderstood Brett's question :) In fact,
as Holger points out, "isPlugged" actually implies that the battery is
being charged.

Andrei

>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
>
> --
> Alexis Menard
> Software Engineer
> INdT Recife Brazil
>
___
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

[Ryosuke Niwa]

On Wed, Jun 15, 2011 at 10:02 AM, Andrei Popescu  wrote:
>
> Because it would know not to start doing things that drain the
> battery. For instance, powering up a 3G antenna to download your
> latest emails could be annoying to users if the battery level is too
> low. 3G takes quite a bit of power and the device would be in danger
> of powering down.


Isn't what you want to use the current battery level?  It doesn't really
matter whether a battery is charging or not if the current battery level is
low because the user might decide to unplug the device as soon as you
started downloading something, in which case, the device can power off if
the batter level is low.

On Wed, Jun 15, 2011 at 10:08 AM, Holger Freyther  wrote:
>
> To answer your question (and leaving aside I am wrong about the isPlugged),
> in
> the example[1] one uses isPlugged + charge level to change the polling
> interval. My point was that just because I have a charger attached, doesn't
> mean that the device is not emptying the battery (be it I do not have
> enough
> current on the USB outlet, a USB hub...).
>

I'd argue that isPlugged should be false in such a case.

- Ryosuke
___
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

[Alexis Menard]

On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu  wrote:
> On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson  wrote:
>> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther  wrote:
>>> On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
 Hi,

>>>

 The use-case for us is to enable content developers to implement 
 rudimentary power management (e.g. to stop "expensive" operations on the 
 page, perhaps save state). I'm not sure if this API is really meant for 
 accurately reporting all the possible power management states of the 
 system as Anssi pointed out.
>>>
>>> Okay, point on complexity taken. My question is what if you want to add
>>> complexity, is there something in the event that prevents that (I have no 
>>> idea
>>> about DOM compatibility issues)? Don't get me wrong I think having more 
>>> device
>>> support is great.
>>>
>>> My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee
>>> that the battery is getting charged. Is this a problem?
>>
>> Why would a web page care about whether the battery is being charged
>> when the device is plugged in?
>>
>
> Because it would know not to start doing things that drain the
> battery. For instance, powering up a 3G antenna to download your
> latest emails could be annoying to users if the battery level is too
> low. 3G takes quite a bit of power and the device would be in danger
> of powering down.

But if the phone is plugged in it can't power down. Most of modern
phones don't switch off anymore even if you have the battery low and
you play games, surf WiFi, go 3G as soon as you plugged it in. What
Brett meant is that it's useless to know that the battery is charging
while the phone is plugged in, you just want to know that it will not
switch off in any case so you can do whatever you want.

>
> Thanks,
> Andrei
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
Alexis Menard
Software Engineer
INdT Recife Brazil
___
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

[Holger Freyther]

On 06/15/2011 06:58 PM, Brett Wilson wrote:

> Why would a web page care about whether the battery is being charged
> when the device is plugged in?

Hi,

aeh, first of all my mind is playing tricks and I could swear that "its
battery is being charged" was not in the isPlugged description so my comment
is void.

To answer your question (and leaving aside I am wrong about the isPlugged), in
the example[1] one uses isPlugged + charge level to change the polling
interval. My point was that just because I have a charger attached, doesn't
mean that the device is not emptying the battery (be it I do not have enough
current on the USB outlet, a USB hub...).



[1] http://dev.w3.org/2009/dap/system-info/battery-status.html#examples


PS: "If the device is current plugged in" is needs probably a ly for the 
current.
___
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

[Andrei Popescu]

On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson  wrote:
> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther  wrote:
>> On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
>>> Hi,
>>>
>>
>>>
>>> The use-case for us is to enable content developers to implement 
>>> rudimentary power management (e.g. to stop "expensive" operations on the 
>>> page, perhaps save state). I'm not sure if this API is really meant for 
>>> accurately reporting all the possible power management states of the system 
>>> as Anssi pointed out.
>>
>> Okay, point on complexity taken. My question is what if you want to add
>> complexity, is there something in the event that prevents that (I have no 
>> idea
>> about DOM compatibility issues)? Don't get me wrong I think having more 
>> device
>> support is great.
>>
>> My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee
>> that the battery is getting charged. Is this a problem?
>
> Why would a web page care about whether the battery is being charged
> when the device is plugged in?
>

Because it would know not to start doing things that drain the
battery. For instance, powering up a 3G antenna to download your
latest emails could be annoying to users if the battery level is too
low. 3G takes quite a bit of power and the device would be in danger
of powering down.

Thanks,
Andrei
___
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

[Brett Wilson]

On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther  wrote:
> On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
>> Hi,
>>
>
>>
>> The use-case for us is to enable content developers to implement rudimentary 
>> power management (e.g. to stop "expensive" operations on the page, perhaps 
>> save state). I'm not sure if this API is really meant for accurately 
>> reporting all the possible power management states of the system as Anssi 
>> pointed out.
>
> Okay, point on complexity taken. My question is what if you want to add
> complexity, is there something in the event that prevents that (I have no idea
> about DOM compatibility issues)? Don't get me wrong I think having more device
> support is great.
>
> My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee
> that the battery is getting charged. Is this a problem?

Why would a web page care about whether the battery is being charged
when the device is plugged in?

Brett
___
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

[Holger Freyther]

On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
> Hi,
> 

> 
> The use-case for us is to enable content developers to implement rudimentary 
> power management (e.g. to stop "expensive" operations on the page, perhaps 
> save state). I'm not sure if this API is really meant for accurately 
> reporting all the possible power management states of the system as Anssi 
> pointed out.

Okay, point on complexity taken. My question is what if you want to add
complexity, is there something in the event that prevents that (I have no idea
about DOM compatibility issues)? Don't get me wrong I think having more device
support is great.

My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee
that the battery is getting charged. Is this a problem?
___
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

[laszlo.1.gombos]

Hi,

> > It seems like the working draft has a couple of TODOs now.  Is the
> spec sufficiently stable?  Are other browser vendors implementing this
> feature?

We have interest implementing the battery-status spec for the QtWebKit (and 
share the common part of the implementation).

> > 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.

The use-case for us is to enable content developers to implement rudimentary 
power management (e.g. to stop "expensive" operations on the page, perhaps save 
state). I'm not sure if this API is really meant for accurately reporting all 
the possible power management states of the system as Anssi pointed out.

Regards,
  Laszlo

___
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

[Anssi Kostiainen]

Hi,

On 15.6.2011, at 17.24, ext Ryosuke Niwa wrote:

> 2011/6/15 권기홍 
> 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

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Kihong Kwon]

> From: ryosuke.n...@gmail.com [mailto:ryosuke.n...@gmail.com] On Behalf Of 
> Ryosuke Niwa

> 2011/6/15 권기홍 
> 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?  

It's quite stable, just before last call.
Here is a editor's draft for LC and there is no TODO in here
(http://dev.w3.org/2009/dap/system-info/battery-status.html)

> Are other browser vendors implementing this feature?

I don't think so, but I'm not sure about that.
But I'd like to make this to an "call for implementation" for this spec.

Kihong

___
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

[Ryosuke Niwa]

2011/6/15 권기홍 
>
> 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?

- Ryosuke
___
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

[Kihong Kwon]

Dear. holger

I agree with you.
This spec is too simple, and I think there may be some other needs.
So I reported your concern to DAP WG for this spec, I'm joining in the DAP WG 
in the W3C.

But this is a minimum set of battery status report to WebApps or a Web pages,
So I think this event and attributes are not dropped.
And if this spec is changed or modified, I'll fix or add my source to the 
WebKit.

In my opinion, the WebKit support this feature is no problem now.
How do you think about?

Thank you for your comment.

BR.
Kihong Kwon

> -Original Message-
> From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
> boun...@lists.webkit.org] On Behalf Of Holger Freyther
> Sent: Wednesday, June 15, 2011 6:41 PM
> To: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
> 
> On 06/15/2011 10:21 AM, 권기홍 wrote:
> > Hi webkit-dev!
> >
> >
> >
> > 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  status/>)
> 
> 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].
> 
> 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)?
> 
> sorry for my two cents
>   holger
> 
> 
> [1]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
> 2.6.git;a=blob;f=Documentation/power/power_supply_class.txt;h=9f16c5178b66
> 2b8f9ec67f3dd7eafd6f4c89e39a;hb=HEAD
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
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

[Holger Freyther]

On 06/15/2011 10:21 AM, 권기홍 wrote:
> Hi webkit-dev! 
> 
>  
> 
> 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 )

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].

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)?

sorry for my two cents
holger


[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/power/power_supply_class.txt;h=9f16c5178b662b8f9ec67f3dd7eafd6f4c89e39a;hb=HEAD
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[권기홍]

Hi webkit-dev!  

 

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 
)

 

This support will be behind the ENABLE_BATTERY_STATUS feature define.

There is a meta bug tracking ther feature’s
dev(https://bugs.webkit.org/show_bug.cgi?id=62698)

 

After adding this to WebCore, I’m going to add this feature to efl port
first.

I expect this feature to be eventually enabled by all ports.

 

Should I go ahead and get this added to build.webkit.org's waterfall?

Looking forward to your comments.

 

Thank you.

Kihong

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[Yuta Kitamura]

On Wed, Jun 15, 2011 at 6:57 AM, Maciej Stachowiak  wrote:

>
> Getting on the latest protocol in place would be great, so long as we
> minimize the risk of anyone shipping a halfway mix.
>

What do you mean by "a halfway mix"?

If you mean we should not ship until the complete feature set is ready, it
is not feasible to do it in one patch and a runtime flag would be desirable;
however, if you just mean we should not break existing features (sending or
receiving text frames, etc.), that's probably not too hard. I intend to keep
existing features on protocol migration.

Like many other features, I want to implement WebSocket features
incrementally; first I'd like to make WebKit understand the new protocol,
then add abilities to send or receive binary frames, and other new additions
and so forth. If we do not want to ship between these processes, I'd be
happy to work on the new protocol behind a flag.

FYI, I uploaded a WIP patch at https://bugs.webkit.org/show_bug.cgi?id=50099,
which changes the protocol implementation in-place (not using runtime or
compile-time flag, yet). This patch tries to keep existing functionalities.

Yuta


>  - Maciej
>
>
> On Jun 14, 2011, at 10:47 AM, Ian Fette (イアンフェッティ) wrote:
>
> I thought Kitamura-san had patches mostly ready to switch us over? Either
> way, I agree we don't want to ship something in the middle, but I would
> verymuch like to see us shipping -09 by July at the latest. We've got a
> protocol that's stable, we've got external partners waiting to use this
> (esp. with binary data), we need to get it out the door.
>
> -Ian
>
> 2011/6/14 Ojan Vafai 
>
>> Reading that bug, Alexey's concerns seem to have been addressed by Firefox
>> and IE shipping the new protocol. We don't want to ship something in between
>> the old and new protocols though, so if it will take multiple patches to
>> switch over, we should probably put it behind a runtime flag.
>>
>>
>> On Tue, Jun 14, 2011 at 10:00 AM, Ian Fette (イアンフェッティ) > > wrote:
>>
>>> We also said previously that we would remove the old protocol due to
>>> security concerns about poisoning caches/proxies. We justified not
>>> immediately disabling -00 like other browsers did by saying that a new
>>> version addressing the issue would come soon. We've had 9 new versions since
>>> and have yet to update, which is not good. Microsoft and Mozilla both are
>>> targeting newer drafts.
>>>
>>> Also, the protocol is in last call, and we're now at the point of just
>>> making editorial changes. It's stable, and it's time to update the
>>> implementation.
>>>
>>>
>>> On Tue, Jun 14, 2011 at 9:49 AM, Adam Barth  wrote:
>>>
 I think it's important to move forward with the new protocol.  I'm not
 sure it matter too much what the transition plan is, but we should
 eventually remove the implementation of the old protocol from WebKit.
 No one else is going to implement the old protocol.

 Adam


 On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura 
 wrote:
 > Hello,
 > I would like to propose to start implementing the new WebSocket
 protocol
 > which is discussed in IETF HyBi working group.
 > Protocol
 > draft:
 http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09
 > JavaScript API draft: http://dev.w3.org/html5/websockets/
 > The new protocol is incompatible with the old one we are currently
 > supporting. New additions include:
 >   - Binary frame support (Blob / ArrayBuffer)
 >   - Frame content masking (to solve security concern raised for the
 old
 > draft)
 >   - Protocol extensions (such as frame compression)
 > Because of the incompatibility, existing services using WebSockets are
 going
 > to break. However, I think this is a necessary cost we have to pay
 > eventually, because:
 >   - Other browsers are going to support the new protocol. (Firefox
 Aurora
 > already includes support for the new protocol.)
 >   - The earlier we switch the protocols, the smaller shock there will
 be.
 > Safari and Chrome are the only browsers that support WebSocket (the
 old
 > protocol) by default.
 >   - There is a security concern raised for the protocol we are
 currently
 > supporting.
 > * How to proceed
 > My original plan was to implement the new protocol directly (i.e.
 replacing
 > the old implementation in-place). However Alexey (ap) objected to
 dropping
 > support for the old protocol immediately.
 > So, I'm currently planning to add a runtime flag to switch the
 WebSocket
 > protocols used by a WebCore's WebSocket implementation. Other
 possibilities
 > are to add a compile-time flag or to use (subversion's) branch, which
 are
 > discussed at:
 > https://bugs.webkit.org/show_bug.cgi?id=60348
 > The discussion in this bug has been stalled for a while, but I really
 would
 > like to move forward. Comments