Re: [whatwg] localStorage, the storage mutex, document.domain, and workers
These two statements are true...
* We can't change the API
* It is seriously flawed
... and therein lies the problem.
I'm sad to have to say it... but I hope this withers and dies an early
death. Putting this in the web platform for perpetuity is a mistake. I don't
support the adoption of this into the platform.
Time to go read the SimpleDatabase proposal.
On Wed, 9 Sep 2009, Darin Fisher wrote:
By the way, you can already pretty much create my acquireLock /
releaseLock API on top of SharedWorkers today, but in a slightly
crappier way.
How? Since the API is completely async, you can't make a spinlock.
You must not have read Darin's proposal. It wasn't a 'lock' at all. It's a
completely async, well-factored primitive.
void acqureFlag('name', callback); // returns immediately in all cases
void releaseFlag('name'); // returns immediately in all cases
The callback is called upon 'flag' acquisition. Its all yours until you call
release. Completely async. I think its self-evident that this can be
composed with a SharedWorker.
Darin's was an example of a good proposal... simple on all dimensions, yet
powerful and broadly applicable... what is not to like? Marry the 'flag'
with a unlocked storage repository and viola, you have something... the
whole is greater than the sum of the parts.
Another lesson to be learned from the LocalStorage debacle is to decompose
things, hashmaps+(implicit)locks+events... it slices and dices (and there's
more)... it was a bad idea to jumble all that together... individually,
minus the implicit, those would make for nice features.
Also, regarding we can't change the API... well it did get changed... the
application of additional implicit locking semantics to IE's API... that is
a material change.
On Thu, Sep 17, 2009 at 5:13 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 17, 2009 at 8:32 PM, Ian Hickson i...@hixie.ch wrote:
LESSONS LEARNT
If we ever define a new API that needs a lock of some kind, the way to do
it is to use a callback, so that the UA can wait for the lock
asynchronously, and then run the callback once it has it. (This is what
the Web Database spec does, for instance.)
When we add more of these features, I think we will need a way to acquire
multiple locks simultaneously before running a callback. (So if we had
localStorage.runTransaction(function(storage) { ... }) and
otherLockingThing.runTransaction(function(thing) { ... }), we could also
have, for example, window.runTransaction(localStorage, otherLockingThing,
function(storage, thing) { ... }).) So it may be worth thinking about what
that API should be and what we will need to add to each feature spec to
support it.
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]
Re: [whatwg] localStorage, the storage mutex, document.domain, and workers
When we add more of these features, I think we will need a way to acquire
multiple locks simultaneously before running a callback. (So if we had
localStorage.runTransaction(function(storage) { ... }) and
otherLockingThing.runTransaction(function(thing) { ... }), we could also
have, for example, window.runTransaction(localStorage, otherLockingThing,
function(storage, thing) { ... }).) So it may be worth thinking about what
that API should be and what we will need to add to each feature spec to
support it.
void acquireFlags(['foo', 'bar', baz'], callback);
Re: [whatwg] object behavior
On Mon, 14 Sep 2009 08:42:10 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
We (Gecko) consider it a bug that a display:none object in a document
doesn't instantiate the plug-in.
BTW, what is the reason for considering it a bug? Is it because:
{
visibility: hidden;
width: 0;
height: 0;
padding: 0;
margin: 0;
line-height: 0;
font-size: 0
border: 0
}
is insufficient and or a pain when you want to load a plug-in but
completely hide it so it's as if it's not there layout-wise?
Or, is there some other reason(s)?
Do you know of any sites that would work better if the bug was fixed? Know
any sites that'd break or begin to unexpectedly load a bunch of object's
that weren't meant to be loaded yet?
If the change is trivial, maybe someone can throw up an experimental FF or
webkit binary with the fix. (Or, provide it as an about:config option in
the trunk builds like the HTML5 parser option is).
Then, I can test how things work and give feedback.
Thanks
--
Michael
Re: [whatwg] object behavior
On 9/18/09 4:57 AM, Michael A. Puls II wrote:
We (Gecko) consider it a bug that a display:none object in a
document doesn't instantiate the plug-in.
BTW, what is the reason for considering it a bug?
Because the current behavior of having the plug-in instantiation handled
by effectively the CSS box means that any time that box changes (e.g.
when you switch from display:block to display:inline) the plug-in is
reinstantiated. Worse yet, it can be reinstantiated due to other
unrelated DOM mutations, depending on what effect they have on CSS
boxes. That's pretty undesirable.
{
visibility: hidden;
width: 0;
height: 0;
padding: 0;
margin: 0;
line-height: 0;
font-size: 0
border: 0
}
is insufficient and or a pain when you want to load a plug-in but
completely hide it so it's as if it's not there layout-wise?
That CSS is a pain _and_ insufficient, depending on context. For
example, consider the situation when the parent of that object is
display:table-row.
Do you know of any sites that would work better if the bug was fixed?
Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=90268 and its
duplicates and depenencies, at least:
http://reviewkaki.blogspot.com/
http://www.youtube.com/
Any site using Dojo 1.0.0 TabContainer with plug-ins in the tabs
and a number of cases where web site developers ended up having to work
around this behavior or reported it without mentioning which site they
were working on.
Funny enough, people want to be able to set paused Flash videos to
display:none and back without losing their position in the video
Know any sites that'd break or begin to unexpectedly load a bunch of
object's that weren't meant to be loaded yet?
Not sure, but since as far as I now Opera and IE both keep the plug-in
alive when the CSS box goes away, as far as I can tell, I'm rather
hoping there won't be many. Not sure what webkit's behavior is here.
Want to test?
If the change is trivial, maybe someone can throw up an experimental FF
or webkit binary with the fix.
If the change were trivial it would have been done back when the bug was
filed, in 2001.
-Boris
Re: [whatwg] Feature requests in WebSocket
Ian Hickson wrote: I don't see how we could hit limits within the OS with Web Sockets. Ian, Consider a webapp with U users, each with W widgets accessing S services on the server. The resources the server needs to service with with multiplexing is O(U+S) But if there is no multiplexing and each widget makes it's own connection to a service (with associated buffers and state machine), then the server resources could scale O(U*W*S). If we make the simplifying assumption that each widget only accesses 1 service, then scaling is still O(U*max(W,S)) Even if the per connection resources are small, it is the non linear scaling that makes this too expensive for large scale deployment. This is a real problem already with HTTP. It is why products like netscalers and network concentrators exist. There is a reason why default ulimit on unix is 1024. There are license conditions on some operating systems that require you to pay more if you want more connections. There are half a million hits if you google too many connections! On Fri, 4 Sep 2009, Jonas Sicking wrote: The authors still have to implement it on the server side, though. Experience from HTTP shows that there are much fewer HTTP server implementing the HTTP protocol, than there are authors using those servers. Experience also shows that HTTP is inanely complicated to implement. The lack of HTTP servers is a bug, not a feature. WebSockets is designed to be more like CGI than HTTP in terms of server-side complexity. Just like there are far more CGI implementations than HTTP implementations, I would expect -- and hope! -- that there will be far more Web Socket implementations than HTTP implementations. It is not a good example and I know of no serious large scale web application that uses CGI. It is only for small scale systems. Imagine the response if you proposed standardizing the next generations of web applications around CGI If you did try, suddenly you would find your world populated with things like SCGI, ISAPI, FastCGI, AJP, WSGI, servlets, portlets and many other attempts to achieve the functionality and scalability required by serious web applications. On Fri, 4 Sep 2009, Greg Wilkins wrote: The server on the server-side could hide the details from the server side developer. The server-side developer is the one writing the server. With HTTP, the server side developer handles requests and has little idea what connection they came over. This is not HTTP. I don't understand your point? Why is the server side any different to the client side. You don't expect most client side developers to write their own browsers and websocket implementations do you? Why do you expect server side developers to write their own servers? TCP/IP already supports all we need here. I don't see why we would want to reinvent this wheel inside a protocol tunneling through TCP. There is no wheel being reinvented. TCP/IP is not there for hold state that is entirely private to the application. TCP/IP is there to create a channel between application (eg browser) to application (eg server). It is the job of the application level protocol (eg HTTP, SMTP, websocket, etc) to route data between an application component (eg widget within page within browser) and application component (eg resource within server). So while you obviously think connections should not be a limiting factor - the reality is that they are and there is only a small design cost to make a protocol that is not wasteful of connections. regards
Re: [whatwg] Global Script proposal.
Commenting in general on this (and not specifically the GlobalScript proposal), I think the outcome of discussions on this list too often is solve it with a single-page Ajax app. In contrast, I think HTML5 should address the needs of multi-page (including all server-side oriented) apps with at least equal weight as the Ajaxy ones. Best regards Mike Wilson Michael Nordman wrote: Agree very much so. On Tue, Sep 15, 2009 at 5:54 PM, Dmitry Titov dim...@chromium.org wrote: it is also an overkill to say that every app should necessarily be a single complex AJAX page morphing itself. That in itself may be a serious limitation.
Re: [whatwg] object behavior
On Fri, 18 Sep 2009 08:18:04 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/18/09 4:57 AM, Michael A. Puls II wrote:
We (Gecko) consider it a bug that a display:none object in a
document doesn't instantiate the plug-in.
BTW, what is the reason for considering it a bug?
Because the current behavior of having the plug-in instantiation handled
by effectively the CSS box means that any time that box changes (e.g.
when you switch from display:block to display:inline) the plug-in is
reinstantiated. Worse yet, it can be reinstantiated due to other
unrelated DOM mutations, depending on what effect they have on CSS
boxes. That's pretty undesirable.
O.K.
{
visibility: hidden;
width: 0;
height: 0;
padding: 0;
margin: 0;
line-height: 0;
font-size: 0
border: 0
}
is insufficient and or a pain when you want to load a plug-in but
completely hide it so it's as if it's not there layout-wise?
That CSS is a pain _and_ insufficient, depending on context. For
example, consider the situation when the parent of that object is
display:table-row.
O.K.
Do you know of any sites that would work better if the bug was fixed?
Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=90268 and its
duplicates and depenencies, at least:
http://reviewkaki.blogspot.com/
http://www.youtube.com/
Any site using Dojo 1.0.0 TabContainer with plug-ins in the tabs
and a number of cases where web site developers ended up having to work
around this behavior or reported it without mentioning which site they
were working on.
Funny enough, people want to be able to set paused Flash videos to
display:none and back without losing their position in the video
Thanks for this.
Know any sites that'd break or begin to unexpectedly load a bunch of
object's that weren't meant to be loaded yet?
Not sure, but since as far as I now Opera and IE both keep the plug-in
alive when the CSS box goes away, as far as I can tell, I'm rather
hoping there won't be many. Not sure what webkit's behavior is here.
Want to test?
Attaching a test.
Results:
O.K., if the initial display state of the object is none, then Opera,
Firefox, Safari and IE don't load the plug-in.
Then, once you set the display to inline, inline-block, block or table for
example, the object will display and fire up the plugin.
Then:
In Opera:
If you switch the display to none, it destroys the plug-in instance.
Setting the display to something else again doesn't restore the previous
plug-in instance. It creates a new one that starts playing from the
beginning.
However, switching between inline, inline-block, block and table just
changes the display and the plug-in keeps playing the file.
In Safari:
Setting to a display of none destroys the plug-in instance like Opera.
However, switching between inline, inline-block, block and table destroys
the current instance and creates a new one each time, which causes the
plug-in to start playing from the beginning.
In IE:
Once the object is shown for the first time, you can set its display to
none, inline, inline-block, block and table and it will just change the
display while letting the plug-in keep playing. This means that setting
the display to none won't destroy the plug-in instance like it does in
other browsers.
In Firefox:
Same as Safari.
So, is it IE's behavior we want here, or Opera's? The difference being
that display: none can kill an already-started plug-in in Opera (and other
browsers right now), while in IE, I think you have to actually remove the
object from the document to get rid of it, or perhaps change its
@type/@classid etc.
Judging by the use-case you mentioned above, IE's exact behavior in these
situations is what's desired?
Or, are you saying that the object should also load the plug-in even
when its display is set to none by default?
Just want to make sure what's desired, if HTML5 matches it and what each
browser has to change.
If the change is trivial, maybe someone can throw up an experimental FF
or webkit binary with the fix.
If the change were trivial it would have been done back when the bug was
filed, in 2001.
O.K. Thanks (thought maybe it was a political issue for why it wasn't
fixed yet instead.)
--
MichaelTitle: object - plug-in loading css
This document contains an object set to display: none by default. Use the dropdown below to change its display to various other values to see what happens in each browser each time you change the value.
none
inline
inline-block
block
table
Before_
You need flash!
_After
Re: [whatwg] object behavior
On 9/18/09 10:21 AM, Michael A. Puls II wrote:
Attaching a test.
Thanks for doing that!
In Opera:
If you switch the display to none, it destroys the plug-in instance.
Setting the display to something else again doesn't restore the previous
plug-in instance. It creates a new one that starts playing from the
beginning.
However, switching between inline, inline-block, block and table just
changes the display and the plug-in keeps playing the file.
Gotcha. Note that due to the way style changes tend to be processed in
browsers this leads to bizarre behavior where exactly how you do your
switching matters. For example, in your testcase in Opera if I do this:
document.getElementsByTagName('object')[0].style.display=none;
document.getElementsByTagName('object')[0].style.display=block;
while the video is running, the video doesn't restart. However if I do:
document.getElementsByTagName('object')[0].style.display=none;
document.body.offsetWidth;
document.getElementsByTagName('object')[0].style.display=block;
then the video does restart.
Note that Gecko and Webkit suffer from a similar inconsistency as long
as the display value was block before the two lines above; if it was
something else the video restarts no matter what, as you noted.
Once the object is shown for the first time, you can set its display
to none, inline, inline-block, block and table and it will just change
the display while letting the plug-in keep playing. This means that
setting the display to none won't destroy the plug-in instance like it
does in other browsers.
In other words, there's hysteresis. The DOM state doesn't uniquely
describe the document state...
So, is it IE's behavior we want here, or Opera's?
In my opinion, neither. We don't want to have plug-in instantiation
depending on the CSS box model at all (and want to instantiate even if
display is none). If that's not feasible, then IE's model is imo
preferable to Opera's sometimes it'll restart sometimes not model
Or, are you saying that the object should also load the plug-in even
when its display is set to none by default?
That seems like the most self-consistent approach to me.
-Boris
[whatwg] status of html5 Custom scheme and content handlers?
RE: 6.8.2 I ask because I am interesting in providing an implementation, and am wondering if it is stable enough to start. It is currently marked as a Working Draft, although I can not find any discussion since late spring, 2009. It reads as if the spec is fairly complete to provide an experimental implementation, but perhaps could use a list of forbidden schemes (eg.http, https, file). Thanks.
Re: [whatwg] Orientation event in Firefox
I'm a little concerned about use of the word orientation for these kinds of events. WebKit on iPhone already uses the term orientation to mean which way up is the device, i.e. in portrait or landscape, right-way-up or upside-down: http://developer.apple.com/iphone/library/documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//apple_ref/doc/uid/TP40006511-SW16 What you're talking about here is getting data from the accelerometer to describe arbitrary positions, so I think it would be clearer if these were called accelerometer events, or something else that distinguishes them from the usage that only applies to the cardinal angles. Simon On Sep 2, 2009, at 2:26 PM, Dave Burke wrote: On Mon, Aug 31, 2009 at 11:06 PM, Doug Turner doug.tur...@gmail.com wrote: Thanks Dave for your comments. I was thinking about update frequency. right now, it is up to the UA (we are using 50ms). To give an explicit example, if you want to run a high pass (say to detect only sudden movements), you might code a simple k-order FIR filter of the form: y[n] = b0.x[n] + b1.x[n-1] + ... + bk.x[n-k] The coefficient values b0 ... bk are a function of the sampling rate (update frequency) and hence needs to be settable or at least known to allow code portability. units -- yes. in g. This is best. magnetometer -- but in a different API, right? I do not see directly how you would combined the two. It's a different API, but (can be) closely related. You can present magnetometer information either as x, y, z of the magnetic field vector or as the special case of compass orientation. For example, Android has the same SensorEvent for both Sensor.TYPE_ACCELEROMETER and Sensor.TYPE_MAGNETIC_FIELD. Lots of interesting use-cases for compass ranging from map tile orientation, navigation, augmented reality, etc. Also see: http://dougt.org/wordpress/2009/08/orientation-update/ for some demos.
Re: [whatwg] object behavior
On Fri, 18 Sep 2009 14:43:39 -0400, Boris Zbarsky bzbar...@mit.edu wrote: On 9/18/09 10:21 AM, Michael A. Puls II wrote: Attaching a test. So, is it IE's behavior we want here, or Opera's? In my opinion, neither. We don't want to have plug-in instantiation depending on the CSS box model at all (and want to instantiate even if display is none). If that's not feasible, then IE's model is imo preferable to Opera's sometimes it'll restart sometimes not model Or, are you saying that the object should also load the plug-in even when its display is set to none by default? That seems like the most self-consistent approach to me. Thanks. Seeing all the inconsistent behavior in browsers now, this sounds like a great idea. But: With object style=display: none data=file.swf?vid=file.flv when the page is parsed (or added to the document), what would happen? Would it be something like this?: 1. Create the plug-in instance. 2. fetch file.swf 3. Give the file.swf stream to the plug-in when it requests it. 4. Fetch file.flv when the plug-in requests it 5. If autoplay, start playing the video (audio only since the object isn't shown) Or, would it stop after #1 where everything else is delayed till the object's display is set to something other than none and is scrolled into view (and, if applicable, the background tab/page that the object is in is focused)? Or, would those optimizations not be triggered at all by display: none, or would it depend on the plug-in or plug-in API or whatever the browser feels like doing? Or, would it stop after #2 is done and continue when the object's display is set to something other than none? In other words, if browsers make it so display: none doesn't prevent the loading of a plug-in, does display: none still prevent the automatic streaming of the file in @data by the browser (for plug-ins, not native types like text/html)? Or, will the browser always fetch the file (unless the plug-in decides to tell the browser to cancel the stream)? The reason I ask is that if existing web pages use multiple object's that load videos for example, that are initially set to display: none and only shown later, then if browsers start fetching all these files as soon as the page loads, it might affect page loading because of bandwidth and cpu etc. It would also affect bandwidth use in general as videos that you might not even watch would be fetched. If this is a concern, then IE's approach of not loading the plug-in if the object is set to display: none when it's attached to the document might make better sense than making display: none not have any affect at all. Or, pages like that (I will try to find some real examples) would have to change things like the following if they don't want an object to stream until they're ready. object style=display: none/object !-- set @type or @data later -- object style=display: none data-type=application/x-shockwave-flash data-data=file.swf/object !-- set @type or @data later by using info in the markup for what plug-in and file to load -- For new pages, going in knowing these things, you just wouldn't add an object to the document until you were ready. Or, should there be some attribute that prevents a plug-in from automatically loading when it's attached to a document like an empty boolean plug-in-disabled? -- Michael
Re: [whatwg] Orientation event in Firefox
Simon Fraser: What you're talking about here is getting data from the accelerometer to describe arbitrary positions, so I think it would be clearer if these were called accelerometer events, or something else that distinguishes them from the usage that only applies to the cardinal angles. What about “attitude”? -- Cameron McCormack ≝ http://mcc.id.au/
