Hi Kihong, All,
On 2.9.2011, at 13.51, ext Kihong Kwon wrote:
>>> Consider a meaning of 'ok' event, it have to be fired immediately after
>>> listener is added.(because device is already 'ok' state.)
>>> Is there any other case about 'full capacity'?
>>
>> Perhaps a couple of lines of (pseudo) code could clarify what you mean by
>> this?
>
> OK! I am wonder the below sentence could be worked in real world.
> - the battery is plugged in, and the battery is being charged or is at its
> full capacity.
>
> Because if the battery is plugged in, and the battery is being charged then
> "ok" event will be fired. And then the event listener will be released,
> because one-time event handler. So if we suppose to this state(plugged and
> charged) is kept going until battery is full charged, then "ok" event have
> to be fired again regarding to the spec's description I indicated. But event
> handler was already release, therefore "ok" event will not be worked at this
> moment.
Ok, I got it. The intent is that in the above scenario the event will not be fired when the battery is fully charged presupposing the isPlugged state does not change at the same time.
> Suppose to it is in the charging state,
>
> Add 'batteryok' listener
> -> Fire a 'ok' event immediately (SPEC: when the battery is plugged in, and
> the battery is being charged)
This is correct behavior.
> -> Battery is full charged
> -> After that a 'ok' event is fired again??? (SPEC: by the battery is
> plugged in and is at its full capacity)
No event is fired, because the isPlugged state does not change. I simplified the description of the battery{ok|critical|low} as follows:
http://dev.w3.org/cvsweb/2009/dap/system-info/battery-status.html.diff?r1=1.38;r2=1.39;f=h
And updated the latest Editor's Draft accordingly:
http://dev.w3.org/2009/dap/system-info/battery-status.html
Does this make the behavior explicit?
Thanks for your feedback.
-Anssi