[Bug 13763] The WebSocket API should provide a polling mechanism too. Only event based capture messages is not good because if a method in a JS-Class send a message the reply arrive in the event han

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13763

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||WONTFIX

--- Comment #6 from Ian 'Hixie' Hickson  2011-08-13 02:45:44 UTC 
---
It's easy to do this already:

   var queue = [];
   websocket.onmessage = function (event) {
 if (queue.length)
   queue.shift()(event);
   };

   // to send and then wait for response:
   websocket.send('foo');
   queue.push(function (event) {
 // rest of function goes here
   });

...or some such. Basically works like polling but without having to worry about
missing other events if you have other things going on.

(code above is untested so may have syntax errors)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Mouse Lock

[Glenn Maynard]

On Fri, Aug 12, 2011 at 7:50 PM, Vincent Scheib  wrote:

> BTW, draft spec currently states, "When mouse lock is enabled clientX,
> clientY, screenX, and screenY must hold constant values as if the mouse were
> located at the center of the mouse lock target element...". I chose this to
> pick something concrete, but not all zeros which may be used as magic values
> in JS code, etc. I'm not strong in this opinion.


Some things that come to mind:

- Delta movement may be received separately from cursor movement.  For
example, an implementation may use WM_MOUSEMOVE to generate mousemove
events, and WM_INPUT to generate mouse delta events, as Klaas pointed out.
These window messages aren't defined relative to each other; a WM_INPUT
event may or may not be followed by a WM_MOUSEMOVE event.  A mouse may
generate WM_INPUT events at 1kHz, but WM_MOUSEMOVE events may only be
generated at 60 or 120Hz.

This means that you'd either end up generating far more mousemove events,
eg. three events with delta information followed by a single event with
cursor information (possibly placing unwanted stress on unrelated mousemove
event handlers--this is a particular problem with Klaas's model, see below);
or discarding information, which also seems undesirable.  Using a separate
event avoids this issue.


- The deltas may not be comparable to corresponding cursor movement.  For
example, mouse cursors often have acceleration and snap-to-axis filters
applied.  I think these filters aren't applied to the data received by
WM_INPUT.  Is this a good thing or not?

It's probably a good thing for an FPS, to avoid snap-to-axis cursor filters
from affecting the viewport.

It's probably a bad thing for dragging Google Maps around.  Having the map
drag at a different rate than the cursor normally moves may be strange.
(Using deltas for dragging is useful: you can continually drag the map,
without having to reposition the mouse cursor every time you reach the edge
of the screen.)


- If mousemove events when locked put clientX, etc. at some arbitrary
position, are mouseover events generated, as if the cursor had actually
moved there?  If deltas do end up packed into mousemove events, I'd suggest
that these properties not change while locked: continue reporting the
last-generated position, as if the unseen cursor is stationary while
locked.  When the mouse is unlocked, the cursor is back where it was
originally; no mouseover events are generated at all, as the cursor
(distinct from the mouse) never moved.


- Klaas suggests an entirely different approach.  Instead of having a
separate delta mode, mouse deltas would always be available.  "Mouse lock"
would be achieved by locking the mouse within a rectangle (a separate
feature entirely from mouse deltas), and hiding the cursor with CSS.
There's some appeal to having delta information always available, without
forcing the cursor to be hidden and locked to use them.  It makes the
dragging (Google Maps) use case simpler: no actual locking is needed, as you
don't care if the mouse cursor stays within the window--so this use case
wouldn't be burdened by any security mechanisms required by locking. The
first two points above still apply here; using a separate mousedelta event
would still make sense in this model.

-- 
Glenn Maynard

Re: [XHR2] responseType and response properties

[Jonas Sicking]

On Fri, Aug 12, 2011 at 5:43 PM, Chris Rogers  wrote:

> Hi Jonas, sorry about the late reply - comments inline:
>
> On Sat, May 21, 2011 at 12:36 AM, Jonas Sicking  wrote:
>
>> Hi All,
>>
>> Firefox 6 is going to add support for the the new responseType and
>> response properties. We would have liked to release these as
>> moz-prefixed properties, but it appears that webkit has already
>> shipped them unprefixed, thus there's not much point in prefixing.
>> Both because we likely can't fix bugs in them anyway, and because
>> sites have already started depending on them.
>>
>
>
>
>>
>> I'd really like to reiterate that we need to be careful about
>> releasing newly minted APIs unprefixed. Even in the case where we here
>> on the list agree on the desired behavior. The Blob.slice mess (which
>> we fortunately managed to save last minute) is a good example of why
>> we should give API time to mature before unprefixing.
>>
>
> Sorry, about that.  I thought we had good agreement about the API.
>

Even on things where there's agreement here it's a good idea to prefix since
once we reach a wider audience (non W3C people as well as developers)
there's a good change that problems will be found.

/ Jonas

Re: [indexeddb] Handling negative parameters for the advance method

[Jonas Sicking]

On Fri, Aug 12, 2011 at 5:49 PM, Israel Hilerio wrote:

> On Friday, August 12, 2011 3:17 PM, Jonas Sicking wrote:
> > On Fri, Aug 12, 2011 at 2:34 PM, Israel Hilerio 
> > wrote:
> > > Since advance is intended to always move the cursor forward, it seems
> we
> > want to only support positive parameter values.  Therefore, I would
> suggest
> > we change its signature to:
> > >
> > > void advance (in unsigned int count);
> > >
> > > If a developer specifies a negative number for it, we could throw an
> > IDBDatabaseException with a value of NON_TRANSIENT_ERR.  A value of zero
> > will do nothing.
> > >
> > > I also noticed that the webIDL spec doesn't define int or unsigned int.
>  It
> > seems we should be using long (for int) and unsigned long (unsigned int).
> > >
> > > Do you agree?
> >
> > Yup. Though I think WebIDL will take care of the handling for when the
> > author specifies a negative value. I.e. WebIDL will specify what
> exception to
> > throw, so we don't need to. Similar to how WebIDL specifies what
> exception
> > to throw if the author specifies too few parameters, or parameters of the
> > wrong type.
> >
> > / Jonas
>
> After researching a bit, there are no exceptions defined in WebIDL when
> passing a negative number to an unsigned long parameter.  The value is
> always converted to some type of positive value.  This will result in some
> erratic behavior that won't generate an exception.  The good news is that
> there is no exception that needs to be thrown :-).
>
> I will work with Eliot to make the changes to the spec and to change all
> "int" references to "long".
>

Oh! You are correct indeed. Though I think it's something that has been
debated if it should be changed or not. In any case let's depend on WebIDL
such that it's consistent with other methods.

Thanks for fixing up the spec guys!

/ Jonas

RE: [indexeddb] Handling negative parameters for the advance method

[Israel Hilerio]

On Friday, August 12, 2011 3:17 PM, Jonas Sicking wrote:
> On Fri, Aug 12, 2011 at 2:34 PM, Israel Hilerio 
> wrote:
> > Since advance is intended to always move the cursor forward, it seems we
> want to only support positive parameter values.  Therefore, I would suggest
> we change its signature to:
> >
> > void advance (in unsigned int count);
> >
> > If a developer specifies a negative number for it, we could throw an
> IDBDatabaseException with a value of NON_TRANSIENT_ERR.  A value of zero
> will do nothing.
> >
> > I also noticed that the webIDL spec doesn't define int or unsigned int.  It
> seems we should be using long (for int) and unsigned long (unsigned int).
> >
> > Do you agree?
> 
> Yup. Though I think WebIDL will take care of the handling for when the
> author specifies a negative value. I.e. WebIDL will specify what exception to
> throw, so we don't need to. Similar to how WebIDL specifies what exception
> to throw if the author specifies too few parameters, or parameters of the
> wrong type.
> 
> / Jonas

After researching a bit, there are no exceptions defined in WebIDL when passing 
a negative number to an unsigned long parameter.  The value is always converted 
to some type of positive value.  This will result in some erratic behavior that 
won't generate an exception.  The good news is that there is no exception that 
needs to be thrown :-).

I will work with Eliot to make the changes to the spec and to change all "int" 
references to "long".

Israel

Re: [indexeddb] What happens after we reach the AutoInc maximum value?

[Jonas Sicking]

On Friday, August 12, 2011, Israel Hilerio  wrote:
> Assuming that we've created an object store with the auto-increment flag
set to true, what is the expected behavior when we reach some type of max
auto-increment value?  Do we want to recycle and start again from zero or do
we stop at the largest number and allow duplicates which will generate a
constraint error?
>
> It seems that if we were to start again from zero and increment the value
every time we find a constraint error, we could reuse the primary key of
previous records that were deleted.
>
> What are your thoughts?

We talked a lot about this a while back. The emails should still be in
archives, but I don't remember dates or subjects. Bing is your friend ;-)

Basically this is almost exclusively a theoretical problem. For normal use
the sun will engulf earth before we run out of numbers :-)

For the problem to arise someone will have to insert a very high number that
did not originate from another object store.

The conclusion we had was that if we bump up against the limit of 64bits, we
should simply make it impossible to insert more rows into the object store.
If a page wants to deal with this situation they'll have to destroy the
object store and create a new one.

Problems actually arise earlier than at the max of 64bits. Once you get into
53 bits you start getting values that JavaScript can't express to to
precision limits. But that too will happen much after civilization as we
know it doesn't exist any more ;-)

/ Jonas

Re: [XHR2] responseType and response properties

[Chris Rogers]

Hi Jonas, sorry about the late reply - comments inline:

On Sat, May 21, 2011 at 12:36 AM, Jonas Sicking  wrote:

> Hi All,
>
> Firefox 6 is going to add support for the the new responseType and
> response properties. We would have liked to release these as
> moz-prefixed properties, but it appears that webkit has already
> shipped them unprefixed, thus there's not much point in prefixing.
> Both because we likely can't fix bugs in them anyway, and because
> sites have already started depending on them.
>



>
> I'd really like to reiterate that we need to be careful about
> releasing newly minted APIs unprefixed. Even in the case where we here
> on the list agree on the desired behavior. The Blob.slice mess (which
> we fortunately managed to save last minute) is a good example of why
> we should give API time to mature before unprefixing.
>

Sorry, about that.  I thought we had good agreement about the API.



>
> So in that spirit, I have a questions about the actual behavior of
> XHR.response:
>
> First, should it return a new ArrayBuffer every time the property is
> accessed (This is how the mozResponseArrayBuffer property in FF4
> behaves), or should it return the same buffer every time? Since
> arraybuffers are mutable, there's a risk that one consumer will modify
> the response such that all other consumers see a modified result. On
> the other hand creating a new buffer every time can be quite expensive
> (at least without complex/slow copy-on-write implementations). It also
> would result in the surprising property that xhr.response !=
> xhr.response.
>
> In FF6 we're aiming to return the same buffer every time. The
> other-consumers-will-see-a-modified-result behavior is unfortunate,
> but similar to how responseXML behaves and hasn't seemed to cause a
> problem there.
>
> Second, what should .response return before the download finishes? It
> would be nice if you could access partial results. However
> ArrayBuffers are fixed size and we won't know the total size until the
> whole download is finished. We could return a copy on each access, but
> again that would be somewhat expensive.
>
> For now we're going to return null during loading in FF6 when
> .responseType is set to "arraybuffer".
>

This is exactly what WebKit is doing right now (returning null when the
loading is not yet complete).  After that point, every access to .response
returns the same ArrayBuffer object.

Chris

Re: [WebIDL] remove modules

[Cameron McCormack]

On 13/08/11 10:49 AM, Paddy Byers wrote:

WAC does refer to interfaces defined in one module from another module;
however, we have not been using scoped names for these references - we
use the unqualified interface name. More or less every WAC module does this.


If WAC is already considering these names globally, and incorrectly 
referring to them without using scoped names, then it seems like they 
are not actually using the functionality that modules affords them.

Re: [WebIDL] remove modules

[Cameron McCormack]

On 13/08/11 5:38 AM, Bryan Sullivan wrote:

How would you propose that such a hypothetical new version deal with
this change?

Take a simple example: the WAC 2.0 Accellerometer API:
http://specs.wacapps.net/2.0/jun2011/deviceapis/accelerometer.html

The purpose of this question is to see if the actual impact of this
change (on specifications, and the related impacts on
implementations) is clear.


Unless the [NamespaceObject] extended attribute is used on a module, 
then the module has no effect on implementation requirements in the 
ECMAScript language binding.  The only thing it provides is a way to 
name interfaces and have them not clash with others the specification 
writer is unaware of.


That brings up a problem: if you have the following IDL

  interface A { };
  module B { interface A { }; };

then we have conflicting requirements for the window.A property.

Do you know if either

  (a) language bindings other than ECMAScript are needed, and
  particular language-specific namespacing/packaging is required; or
  (b) the [NamespaceObject] extended attribute is used in any of these
  specifications?

If neither is the case, then I would say just remove the "module { ... 
};" declarations from the IDL in these specifications.  If some 
interface names currently in modules would clash with others, then you 
should rename them, because they are already conflicting in the 
ECMAScript binding as I mention above.



On the second point (a WAC extension for modules), how would that be
defined? If WAC (and OMA) really needed such an extension, why would
W3C object to it being a part of the Web IDL spec (if it is not used
in W3C specs then fine, but the universe of Web API specifications is
larger than W3C...).


It's a maintenance/complexity thing: given we are focusing on the web 
platform here, does it make sense to spend time maintaining a feature 
which is used only in non-web contexts?

[indexeddb] What happens after we reach the AutoInc maximum value?

[Israel Hilerio]

Assuming that we've created an object store with the auto-increment flag set to 
true, what is the expected behavior when we reach some type of max 
auto-increment value?  Do we want to recycle and start again from zero or do we 
stop at the largest number and allow duplicates which will generate a 
constraint error?

It seems that if we were to start again from zero and increment the value every 
time we find a constraint error, we could reuse the primary key of previous 
records that were deleted.

What are your thoughts?

Israel

Re: Mouse Lock

[Vincent Scheib]

BTW, draft spec currently states, "When mouse lock is enabled clientX,
clientY, screenX, and screenY must hold constant values as if the mouse were
located at the center of the mouse lock target element...". I chose this to
pick something concrete, but not all zeros which may be used as magic values
in JS code, etc. I'm not strong in this opinion.

On Fri, Aug 12, 2011 at 3:20 PM, Tab Atkins Jr. wrote:

> On Fri, Aug 12, 2011 at 3:14 PM, Jonas Sicking  wrote:
> > And if the user doesn't approve the lock you do what? Not let them
> > play your game?
>
> Maybe.  It really is impossible to play a game with a control scheme
> based on WASD+mouselook if you can't get a lock.
>
> Alternately, you can switch to a different (less good) control scheme
> if you can't acquire a lock.  This is not acceptable behavior for the
> default case, though.  WASD+mouselook is a very entrenched and natural
> control scheme; anything else will  be much harder to use.
>
> The difference isn't always quite this extreme; sometimes the
> experience is only moderately degraded, instead of majorly, if you
> can't get a lock.  For example, edge scrolling in StarCraft,
> Civilization, or similar games is really useful.  You could play the
> game without it, it would just be annoying.  (The gamedev would have
> to implement some other way to do scrolling, either a modifier key +
> arrows, or dedicating the drag action to scrolling, or similar.)
>
> ~TJ
>

Re: [WebIDL] remove modules

[Paddy Byers]

Hi,

E.g., "The Accelerometer API" and just remove "module" from the title
> and from the WebIDL. I don't think any spec in WAC references any
> other IDL in another module in the way that WebIDL defines... so there
> would be no impact.


WAC does refer to interfaces defined in one module from another module;
however, we have not been using scoped names for these references - we use
the unqualified interface name. More or less every WAC module does this.

However, I did notice that the Webinos draft APIs [1] are referencing
foreign interfaces using scoped names, and I think Dom has been active in
that work - perhaps he can comment?

Paddy

1: http://dev.webinos.org/specifications/draft/

Re: [WebIDL] remove modules

[Paddy Byers]

Hi,

I don't think any runtimes would break... probably just this would
> need some changes:
> http://widl.webvm.net/
>
> (though it is unlikely that the widl processor conforms to whatever
> the latest draft of WebIDL is)
>

Yes, it implements the grammar in the latest editor's draft. Dom has been
active in maintaining it.

Paddy

Re: [WebIDL] remove modules

[Paddy Byers]

Hi,,

If modules are removed from the Web IDL spec, what running code e.g.
> browsers, web/widget runtimes, IDEs, test cases, etc. will no longer comply
> with the spec (looking for real breakages here)?
>
> If WAC needs that type of functionality, could they define their own IDL
> extension?
>

Of course WAC can define something. The question is whether or not there is
general utility in having modules as a way of logically grouping a set of
interface definitions.

The thing we do that will break is that a module is used to group the
interfaces that are associated with a particular feature. For example, when
a programmer requests a feature - say
http://www.w3.org/TR/geolocation-API/- then the interfaces that are
enabled are exactly those belonging to the
geolocation module. Without a module to group these interfaces, all we have
is that the feature URI and the interfaces are implicitly connected by being
defined in the same document.

Concretely, this is used in the WAC SDK. When a widget's config.xml includes
a feature element, then the interfaces and prototypes associated with that
module are instantiated for content assistance purposes. If we only had that
grouping implicit, or in prose in the spec, we would need to preprocess the
WebIDL ad add further metadata, in order to include each new API into the
SDK.

Thanks - Paddy

Re: Mouse Lock

[Tab Atkins Jr.]

On Fri, Aug 12, 2011 at 3:14 PM, Jonas Sicking  wrote:
> And if the user doesn't approve the lock you do what? Not let them
> play your game?

Maybe.  It really is impossible to play a game with a control scheme
based on WASD+mouselook if you can't get a lock.

Alternately, you can switch to a different (less good) control scheme
if you can't acquire a lock.  This is not acceptable behavior for the
default case, though.  WASD+mouselook is a very entrenched and natural
control scheme; anything else will  be much harder to use.

The difference isn't always quite this extreme; sometimes the
experience is only moderately degraded, instead of majorly, if you
can't get a lock.  For example, edge scrolling in StarCraft,
Civilization, or similar games is really useful.  You could play the
game without it, it would just be annoying.  (The gamedev would have
to implement some other way to do scrolling, either a modifier key +
arrows, or dedicating the drag action to scrolling, or similar.)

~TJ

Re: [indexeddb] Handing negative parameters for the advance method

[Jonas Sicking]

On Fri, Aug 12, 2011 at 2:34 PM, Israel Hilerio  wrote:
> Since advance is intended to always move the cursor forward, it seems we want 
> to only support positive parameter values.  Therefore, I would suggest we 
> change its signature to:
>
> void advance (in unsigned int count);
>
> If a developer specifies a negative number for it, we could throw an 
> IDBDatabaseException with a value of NON_TRANSIENT_ERR.  A value of zero will 
> do nothing.
>
> I also noticed that the webIDL spec doesn't define int or unsigned int.  It 
> seems we should be using long (for int) and unsigned long (unsigned int).
>
> Do you agree?

Yup. Though I think WebIDL will take care of the handling for when the
author specifies a negative value. I.e. WebIDL will specify what
exception to throw, so we don't need to. Similar to how WebIDL
specifies what exception to throw if the author specifies too few
parameters, or parameters of the wrong type.

/ Jonas

Re: Mouse Lock

[Jonas Sicking]

On Fri, Aug 12, 2011 at 2:12 PM, Tab Atkins Jr.  wrote:
> On Fri, Aug 12, 2011 at 2:06 PM, Jonas Sicking  wrote:
>> On Fri, Aug 12, 2011 at 1:54 PM, Tab Atkins Jr.  wrote:
>>> On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking  wrote:
 If we expose delta information in all mouse events, which seems like
 it could be a good idea, then what is the usecase for the success
 callback for mouselock?

 I was under the impression that that was so that the page could start
 treating mousemove events differently, but if all mousemove events
 have deltas, then that won't be needed, no?
>>>
>>> No, it's still definitely needed.  You can't do an FPS with non-locked
>>> deltas; the user will end up moving their mouse off the screen.
>>>
>>> The use-cases for delta-without-mouselock are pretty separate from
>>> those for delta-within-mouselock.
>>
>> Sure, I wasn't saying that mouselock wasn't needed. I was asking what
>> the use case for the 'success' callback to the mouseLock was.
>
> So you can tell that you're locked.  Without that assurance, you can't
> do a game using WASD+mouselook, because if the mouse isn't locked the
> user will end up scrolling out of your active area.  You'll have to
> make sure the mouse is actually locked *somehow*; might as well be via
> a success callback.

And if the user doesn't approve the lock you do what? Not let them
play your game?

/ Jonas

[indexeddb] Handing negative parameters for the advance method

[Israel Hilerio]

Since advance is intended to always move the cursor forward, it seems we want 
to only support positive parameter values.  Therefore, I would suggest we 
change its signature to:

void advance (in unsigned int count);

If a developer specifies a negative number for it, we could throw an 
IDBDatabaseException with a value of NON_TRANSIENT_ERR.  A value of zero will 
do nothing.

I also noticed that the webIDL spec doesn't define int or unsigned int.  It 
seems we should be using long (for int) and unsigned long (unsigned int). 

Do you agree?

Israel

Re: [WebIDL] remove modules

[Bryan Sullivan]

Marcos,

So OK, if we just remove the module keyword from the
accelerometer
 definition, you're saying that will have no effect upon any aspect of the
implementation of the accelerometer API?

In terms of the need for the module keyword, I'm waiting for WAC members
(who seem the main users of this so far) to either voice opinions or accept
the change. My main concern is potential impact to the specs and
implementations. If there is none, then clearly there should be no issue
with removing the module keyword.

Re objections to this feature, when I referred to "W3C" I was of course
meaning the consensus of the Webapps group, which represents the W3C in this
decision.

Bryan

On Fri, Aug 12, 2011 at 12:41 PM, Marcos Caceres
wrote:

> On Fri, Aug 12, 2011 at 7:38 PM, Bryan Sullivan  wrote:
> > I don't believe the concern is about changes to Web IDL breaking any
> running
> > code (is that possible in any case? Web IDL is just a specification
> > language...).
> >
> > But it could "break" specifications (affect them in a way that does
> impact
> > the code which implements them). Future versions of a spec that did have
> > modules defined would have to change to comply with a new Web IDL version
> > without modules. How would you propose that such a hypothetical new
> version
> > deal with this change?
> >
> > Take a simple example: the WAC 2.0 Accellerometer API:
> > http://specs.wacapps.net/2.0/jun2011/deviceapis/accelerometer.html
> >
> > The purpose of this question is to see if the actual impact of this
> change
> > (on specifications, and the related impacts on implementations) is clear.
> >
> > On the second point (a WAC extension for modules), how would that be
> > defined?
>
> E.g., "The Accelerometer API" and just remove "module" from the title
> and from the WebIDL. I don't think any spec in WAC references any
> other IDL in another module in the way that WebIDL defines... so there
> would be no impact. Like you said, it's mostly a specification
> language and most of these specifications are written in HTML... so
> just hyperlink to the API you want to use from another spec (i.e.,
> what was once a module). It's common for specs to do this already
> (e.g., interface SomeNewEvent : Event {} ... where Event links to DOM
> Core's definition of an Event).
>
> > If WAC (and OMA) really needed such an extension, why would W3C
> > object to it being a part of the Web IDL spec (if it is not used in W3C
> > specs then fine, but the universe of Web API specifications is larger
> than
> > W3C...).
>
> I don't think anyone was "objecting" (particularly not "the W3C",
> which is just an innocent bystander); the question is if there is any
> value/use case for module and is anyone really using it beyond what
> could be done with prose?
>
> I personally don't see much use for modules... they are a nice
> grouping-thingy, but just seem to add more complexity.
>
> --
> Marcos Caceres
> http://datadriven.com.au
>

Re: Mouse Lock

[Tab Atkins Jr.]

On Fri, Aug 12, 2011 at 2:06 PM, Jonas Sicking  wrote:
> On Fri, Aug 12, 2011 at 1:54 PM, Tab Atkins Jr.  wrote:
>> On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking  wrote:
>>> If we expose delta information in all mouse events, which seems like
>>> it could be a good idea, then what is the usecase for the success
>>> callback for mouselock?
>>>
>>> I was under the impression that that was so that the page could start
>>> treating mousemove events differently, but if all mousemove events
>>> have deltas, then that won't be needed, no?
>>
>> No, it's still definitely needed.  You can't do an FPS with non-locked
>> deltas; the user will end up moving their mouse off the screen.
>>
>> The use-cases for delta-without-mouselock are pretty separate from
>> those for delta-within-mouselock.
>
> Sure, I wasn't saying that mouselock wasn't needed. I was asking what
> the use case for the 'success' callback to the mouseLock was.

So you can tell that you're locked.  Without that assurance, you can't
do a game using WASD+mouselook, because if the mouse isn't locked the
user will end up scrolling out of your active area.  You'll have to
make sure the mouse is actually locked *somehow*; might as well be via
a success callback.

~TJ

Re: Mouse Lock

[Jonas Sicking]

On Fri, Aug 12, 2011 at 1:54 PM, Tab Atkins Jr.  wrote:
> On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking  wrote:
>> On Fri, Aug 12, 2011 at 9:53 AM, Tab Atkins Jr.  wrote:
>>> On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
>>>  wrote:
 If your implementation had to warp the mouse cursor on Windows to get
 accurate delta information, the mouse position in the existing mouse
 events would no longer be very meaningful and a new event type seemed
 more logical. But assuming Klaas is right, we no longer need to worry
 about this. It seems we can unconditionally add delta information to
 existing mouse events. So I withdraw that comment.
>>>
>>> I suspect that, while locked, we still don't actually want to expose
>>> the various x and y properties for the mouse.  I agree with Vincent
>>> that the *other* mouseevent properties are all useful, though, and
>>> that the delta properties are really useful in non-mouselock
>>> situations.
>>>
>>> We should just zero all the position information.  Even if we can
>>> switch all OSes to a delta mode, the position will be arbitrary and
>>> meaningless.  This seems easier than making a new type of mouse event
>>> that exposes all of normal mouse events except the position, and
>>> ensuring that the two stay in sync when we add new info.
>>
>> If we expose delta information in all mouse events, which seems like
>> it could be a good idea, then what is the usecase for the success
>> callback for mouselock?
>>
>> I was under the impression that that was so that the page could start
>> treating mousemove events differently, but if all mousemove events
>> have deltas, then that won't be needed, no?
>
> No, it's still definitely needed.  You can't do an FPS with non-locked
> deltas; the user will end up moving their mouse off the screen.
>
> The use-cases for delta-without-mouselock are pretty separate from
> those for delta-within-mouselock.

Sure, I wasn't saying that mouselock wasn't needed. I was asking what
the use case for the 'success' callback to the mouseLock was.

/ Jonas

Re: Mouse Lock

[Tab Atkins Jr.]

On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking  wrote:
> On Fri, Aug 12, 2011 at 9:53 AM, Tab Atkins Jr.  wrote:
>> On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
>>  wrote:
>>> If your implementation had to warp the mouse cursor on Windows to get
>>> accurate delta information, the mouse position in the existing mouse
>>> events would no longer be very meaningful and a new event type seemed
>>> more logical. But assuming Klaas is right, we no longer need to worry
>>> about this. It seems we can unconditionally add delta information to
>>> existing mouse events. So I withdraw that comment.
>>
>> I suspect that, while locked, we still don't actually want to expose
>> the various x and y properties for the mouse.  I agree with Vincent
>> that the *other* mouseevent properties are all useful, though, and
>> that the delta properties are really useful in non-mouselock
>> situations.
>>
>> We should just zero all the position information.  Even if we can
>> switch all OSes to a delta mode, the position will be arbitrary and
>> meaningless.  This seems easier than making a new type of mouse event
>> that exposes all of normal mouse events except the position, and
>> ensuring that the two stay in sync when we add new info.
>
> If we expose delta information in all mouse events, which seems like
> it could be a good idea, then what is the usecase for the success
> callback for mouselock?
>
> I was under the impression that that was so that the page could start
> treating mousemove events differently, but if all mousemove events
> have deltas, then that won't be needed, no?

No, it's still definitely needed.  You can't do an FPS with non-locked
deltas; the user will end up moving their mouse off the screen.

The use-cases for delta-without-mouselock are pretty separate from
those for delta-within-mouselock.

~TJ

Re: Mouse Lock

[Jonas Sicking]

On Fri, Aug 12, 2011 at 9:53 AM, Tab Atkins Jr.  wrote:
> On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
>  wrote:
>> If your implementation had to warp the mouse cursor on Windows to get
>> accurate delta information, the mouse position in the existing mouse
>> events would no longer be very meaningful and a new event type seemed
>> more logical. But assuming Klaas is right, we no longer need to worry
>> about this. It seems we can unconditionally add delta information to
>> existing mouse events. So I withdraw that comment.
>
> I suspect that, while locked, we still don't actually want to expose
> the various x and y properties for the mouse.  I agree with Vincent
> that the *other* mouseevent properties are all useful, though, and
> that the delta properties are really useful in non-mouselock
> situations.
>
> We should just zero all the position information.  Even if we can
> switch all OSes to a delta mode, the position will be arbitrary and
> meaningless.  This seems easier than making a new type of mouse event
> that exposes all of normal mouse events except the position, and
> ensuring that the two stay in sync when we add new info.

If we expose delta information in all mouse events, which seems like
it could be a good idea, then what is the usecase for the success
callback for mouselock?

I was under the impression that that was so that the page could start
treating mousemove events differently, but if all mousemove events
have deltas, then that won't be needed, no?

/ Jonas

Re: [WebIDL] remove modules

[Marcos Caceres]

On Fri, Aug 12, 2011 at 7:38 PM, Bryan Sullivan  wrote:
> I don't believe the concern is about changes to Web IDL breaking any running
> code (is that possible in any case? Web IDL is just a specification
> language...).
>
> But it could "break" specifications (affect them in a way that does impact
> the code which implements them). Future versions of a spec that did have
> modules defined would have to change to comply with a new Web IDL version
> without modules. How would you propose that such a hypothetical new version
> deal with this change?
>
> Take a simple example: the WAC 2.0 Accellerometer API:
> http://specs.wacapps.net/2.0/jun2011/deviceapis/accelerometer.html
>
> The purpose of this question is to see if the actual impact of this change
> (on specifications, and the related impacts on implementations) is clear.
>
> On the second point (a WAC extension for modules), how would that be
> defined?

E.g., "The Accelerometer API" and just remove "module" from the title
and from the WebIDL. I don't think any spec in WAC references any
other IDL in another module in the way that WebIDL defines... so there
would be no impact. Like you said, it's mostly a specification
language and most of these specifications are written in HTML... so
just hyperlink to the API you want to use from another spec (i.e.,
what was once a module). It's common for specs to do this already
(e.g., interface SomeNewEvent : Event {} ... where Event links to DOM
Core's definition of an Event).

> If WAC (and OMA) really needed such an extension, why would W3C
> object to it being a part of the Web IDL spec (if it is not used in W3C
> specs then fine, but the universe of Web API specifications is larger than
> W3C...).

I don't think anyone was "objecting" (particularly not "the W3C",
which is just an innocent bystander); the question is if there is any
value/use case for module and is anyone really using it beyond what
could be done with prose?

I personally don't see much use for modules... they are a nice
grouping-thingy, but just seem to add more complexity.

-- 
Marcos Caceres
http://datadriven.com.au

Re: [XHR] support for streaming data

[Charles Pritchard]

On 8/12/11 12:03 PM, Anne van Kesteren wrote:
On Tue, 09 Aug 2011 02:13:20 +0200, Jonas Sicking  
wrote:

XHR Level 2 does wonders for making XMLHttpRequest better. However
there is one problem that we have run into with "streaming" data.


Before we add yet another set of features, when are we going to 
attempt to get interoperability on the current feature set? 

Some time after adding another set of features, I'd imagine.
This has always been the way of XHR.

We've got a pretty strong case for chunked array buffer as a -single- 
feature.
Between Mozilla and WebKit, I'd imagine one of the vendors will 
implement this year.


I wrote a test suite of sorts for features prior to XMLHttpRequest 
Level 2, but so far it has seen little feedback. Also nobody has 
contributed tests for the new features added to XMLHttpRequest Level 2.


Where's your test set from prior? I'm booked this month, but I'd be 
happy to pick it up next month.


-Charles

Re: [XHR] support for streaming data

[Anne van Kesteren]

On Tue, 09 Aug 2011 02:13:20 +0200, Jonas Sicking  wrote:

XHR Level 2 does wonders for making XMLHttpRequest better. However
there is one problem that we have run into with "streaming" data.


Before we add yet another set of features, when are we going to attempt to  
get interoperability on the current feature set? I wrote a test suite of  
sorts for features prior to XMLHttpRequest Level 2, but so far it has seen  
little feedback. Also nobody has contributed tests for the new features  
added to XMLHttpRequest Level 2.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [WebIDL] remove modules

[Bryan Sullivan]

I don't believe the concern is about changes to Web IDL breaking any running
code (is that possible in any case? Web IDL is just a specification
language...). 

But it could "break" specifications (affect them in a way that does impact
the code which implements them). Future versions of a spec that did have
modules defined would have to change to comply with a new Web IDL version
without modules. How would you propose that such a hypothetical new version
deal with this change?

Take a simple example: the WAC 2.0 Accellerometer API:
http://specs.wacapps.net/2.0/jun2011/deviceapis/accelerometer.html

The purpose of this question is to see if the actual impact of this change
(on specifications, and the related impacts on implementations) is clear.

On the second point (a WAC extension for modules), how would that be
defined? If WAC (and OMA) really needed such an extension, why would W3C
object to it being a part of the Web IDL spec (if it is not used in W3C
specs then fine, but the universe of Web API specifications is larger than
W3C...).

Thanks,
Bryan Sullivan | AT&T

On 8/12/11 5:46 AM, "Marcos Caceres"  wrote:

> On Fri, Aug 12, 2011 at 2:41 PM, Arthur Barstow  wrote:
>> Hi Paddy,
>> 
>> If modules are removed from the Web IDL spec, what running code e.g.
>> browsers, web/widget runtimes, IDEs, test cases, etc. will no longer comply
>> with the spec (looking for real breakages here)?
> 
> I don't think any runtimes would break... probably just this would
> need some changes:
> http://widl.webvm.net/
> 
> (though it is unlikely that the widl processor conforms to whatever
> the latest draft of WebIDL is)
> 
>> If WAC needs that type of functionality, could they define their own IDL
>> extension?
> 
> That would probably be fine.
> 

Re: Rescinding the DOM 2 View Recommendation?

[Aryeh Gregor]

On Fri, Aug 12, 2011 at 7:42 AM, Arthur Barstow  wrote:
> Anne, Ms2ger, All - can you live with adding a note to D2V rather than going
> down the rescind path?

I'm fine with having prominent notices in obsolescent standards
pointing readers to the up-to-date work.  If rescinding is too much of
a hassle, there's no reason to go to the trouble.  Also, from a
Process point of view I doubt it makes sense to rescind a
Recommendation in favor of an Editor's Draft.

Re: Mouse Lock

[Tab Atkins Jr.]

On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
 wrote:
> If your implementation had to warp the mouse cursor on Windows to get
> accurate delta information, the mouse position in the existing mouse
> events would no longer be very meaningful and a new event type seemed
> more logical. But assuming Klaas is right, we no longer need to worry
> about this. It seems we can unconditionally add delta information to
> existing mouse events. So I withdraw that comment.

I suspect that, while locked, we still don't actually want to expose
the various x and y properties for the mouse.  I agree with Vincent
that the *other* mouseevent properties are all useful, though, and
that the delta properties are really useful in non-mouselock
situations.

We should just zero all the position information.  Even if we can
switch all OSes to a delta mode, the position will be arbitrary and
meaningless.  This seems easier than making a new type of mouse event
that exposes all of normal mouse events except the position, and
ensuring that the two stay in sync when we add new info.

~TJ

RE: Rescinding the DOM 2 View Recommendation?

[Adrian Bateman]

On Wednesday, August 10, 2011 10:18 AM, Arthur Barstow wrote:
> Anne, Ms2ger, All,
> 
> Anne and others proposed in [Proposal] the DOM 2 View Recommendation
> [D2V] be "rescinded". The rescinding process is defined in the Process
> Document [Rescind]. However,  Ian Jacobs just indicated in IRC
> [#webapps] it has never actually been used.
> 
> One process requirement for rescinding a Recommendation is a "separate
> rationale for the proposal to rescind". Would you Anne and/or someone
> please create the rationale document (using WebApps' wiki)? I think it
> should include a clear problem statement i.e. identify the interop
> issues this Recommendation is causing as well as the alternative (new)
> solution.
> 
> If anyone has comments about this proposal, please speak up.

Microsoft is opposed to rescinding the DOM L2 View Recommendation. Our
customers value stable Recommendation documents that they can use to
compare implementations against and we document Internet Explorer's
variations against all completed W3C Recommendations. For IE9 we targeted
the DOM L2 View spec and our support documentation is available in MSDN [1].
Trying to maintain such documentation for a moving target such as the
HTML5 spec is too costly and doesn't provide our customers with what they
need.

Microsoft proposes that the W3C maintain the Recommendation status for
DOM L2 View until a stable alternative is available. A note in the status
section indicating that on-going work to supersede this document is being
done in the HTML5 specification would be appropriate.

[1] http://msdn.microsoft.com/en-us/library/ff460623(v=VS.85).aspx

Re: [WebIDL] remove modules

[Marcos Caceres]

On Fri, Aug 12, 2011 at 2:41 PM, Arthur Barstow  wrote:
> Hi Paddy,
>
> If modules are removed from the Web IDL spec, what running code e.g.
> browsers, web/widget runtimes, IDEs, test cases, etc. will no longer comply
> with the spec (looking for real breakages here)?

I don't think any runtimes would break... probably just this would
need some changes:
http://widl.webvm.net/

(though it is unlikely that the widl processor conforms to whatever
the latest draft of WebIDL is)

> If WAC needs that type of functionality, could they define their own IDL
> extension?

That would probably be fine.


-- 
Marcos Caceres
http://datadriven.com.au

Re: [WebIDL] remove modules

[Arthur Barstow]

Hi Paddy,

If modules are removed from the Web IDL spec, what running code e.g. 
browsers, web/widget runtimes, IDEs, test cases, etc. will no longer 
comply with the spec (looking for real breakages here)?


If WAC needs that type of functionality, could they define their own IDL 
extension?


-ArtB

On 8/12/11 2:27 AM, ext Paddy Byers wrote:
(Previously send to public-script-coord but I was asked to forward to 
webapps.)


Hi,

Two things to be aware of if we drop the feature:

One, BONDI folks were using IDL modules, IIRC. Although I think their
spec stabilised well before now, so presumably they’re dependent on an
earlier WD of Web IDL, and thus it’s probably not a big deal to
drop the
feature, aside from the fact that we should focus on the Web and not
other concerns.


The BONDI spec has been superseded by the WAC spec [1] and this still 
uses modules. The WAC spec is frozen and there is already a growing 
list of incompatibilities between the WAC WebIDL and the latest WebIDL 
spec - so in any event there would need to be changes if WAC creates a 
new revision of its spec and wishes to migrate to the latest WebIDL.


However, the motivation for using modules I think still stands, in 
that a module is the unit by which support for a given feature is enabled.


That is, we associate a WebIDL module with one or more features (in 
the sense of [2]). If one or more of the features associated with a 
module is successfully requested, then all of the interfaces belonging 
to that module are available, and all of the objects (eg interface 
objects) entailed by those interfaces are instantiated.


If modules are dropped from WebIDL, then there would still be a desire 
I think to have a logical grouping of interfaces, but we would have to 
specify that in prose instead of in WebIDL.


Thanks - Paddy

[1]:http://specs.wacapps.net/2.0/jun2011/deviceapis/webidl.html
[2]: http://www.w3.org/TR/widgets/#the-feature-element-and-its-attributes

Re: Rescinding the DOM 2 View Recommendation?

[Arthur Barstow]

On 8/10/11 6:02 PM, ext Doug Schepers wrote:
After discussion with PLH and Ian Jacobs, and I don't think it's 
necessary for us to go through the additional overhead of rescinding 
the DOM 2 View specification.


Instead, PLH and I support Anne's original proposal to simply update 
the status section of the spec to point people to the HTML5 spec.  We 
could add wording like:


[[
Updated definitions of the 'document' and 'defaultView' attributes are 
now defined by the HTML5 specification.  Other concepts in this 
specification may not be necessary for implementation in general user 
agents such as Web browsers.

]]

I don't object to rescinding it, I simply prefer the option with the 
least process necessary.


Anne, Ms2ger, All - can you live with adding a note to D2V rather than 
going down the rescind path?


-AB

Reminder: RfC: Last Call Working Draft of Web IDL; deadline August 23

[Arthur Barstow]

Reminder: August 23 is the comment deadline for the 12-July-2011 Last 
Call Working Draft of Web IDL:


http://www.w3.org/TR/2011/WD-WebIDL-20110712/

 Original Message 
Subject:RfC: Last Call Working Draft of Web IDL; deadline August 23
Resent-Date:Tue, 12 Jul 2011 16:14:30 +
Resent-From:
Date:   Tue, 12 Jul 2011 12:14:00 -0400
From:   ext Arthur Barstow 
Reply-To:   public-script-coord 
To: 	public-webapps , public-script-coord 





On July 12 a Last Call Working Draft of Web IDL was published:

  http://www.w3.org/TR/2011/WD-WebIDL-20110712/

The deadline for comments is August 23 and all comments should be sent to:

   public-script-co...@w3.org

Cameron, Philippe - if you think it is necessary, please fwd this e-mail
to ECMA TC39.

-AB

[Bug 13763] New: The WebSocket API should provide a polling mechanism too. Only event based capture messages is not good because if a method in a JS-Class send a message the reply arrive in the even

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13763

   Summary: The WebSocket API should provide a polling mechanism
too. Only event based capture messages is not good
because if a method in a JS-Class send a message the
reply arrive in the event handler. The event handler
has no access (if no global var exists) to th
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#the
-websocket-interface
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification:
http://www.whatwg.org/specs/web-apps/current-work/complete/network.html
Multipage: http://www.whatwg.org/C#the-websocket-interface
Complete: http://www.whatwg.org/c#the-websocket-interface

Comment:
The WebSocket API should provide a polling mechanism too. Only event based
capture messages is not good because if a method in a JS-Class send a message
the reply arrive in the event handler. The event handler has no access (if no
global var exists) to the class instance who send the request. With a polling
mechanism the class instance can wait for a reply and with webworkers there
should be no problem with waiting and polling.

Posted from: 93.217.122.57
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101
Firefox/5.0

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.