Re: [chromium-html5] LocalStorage inside Worker
I think the idea is that JavaScript should not do unexpected things. The suggestion to only make local storage accessible from inside callbacks seems the best suggestion so far. Cheers, Keean. On 11 January 2011 06:20, Felix Halim felix.ha...@gmail.com wrote: On Tue, Jan 11, 2011 at 1:02 PM, Glenn Maynard gl...@zewt.org wrote: localStorage should focus on simplicity and performance and ignore thread safety since, IMHO, localStorage is used for UI purposes or preferences settings (not data itself). If you open two tab, you change settings in one tab, you can just refresh the other tab and I believe both of them will have the same UI state again. It's used for data storage, too, particularly since it's widely available in production; IndexedDB is not. Then, why don't introduce a new storage, like localStorageNTS (NTS = non thread safe), and allow this storage to be used everywhere... Felix Halim
Re: [chromium-html5] LocalStorage inside Worker
I think I already came to the same conclusion... JavaScript has no control over effects, which devalues STM. In the absence of effect control, apparent serialisation (of transactions) is the best you can do. What we need is a purely functional JavaScript, it makes threading so much easier ;-) Cheers, Keean. On 10 January 2011 23:42, Robert O'Callahan rob...@ocallahan.org wrote: STM is not a panacea. Read http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspxif you haven't already. In Haskell, where you have powerful control over effects, it may work well, but Javascript isn't anything like that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [IndexedDB] Events and requests
Comments inline:
On 11 January 2011 07:11, Axel Rauschmayer a...@rauschma.de wrote:
Coming back to the initial message in this thread (at the very bottom):
= General rule of thumb: clearly separate input data and output data.
Using JavaScript dynamic nature, things could look as follows:
indexedDB.open('AddressBook', 'Address Book', {
success: function(evt) {
},
error: function(evt) {
}
});
Personally I prefer a single callback passed an object.
indexedDB.open('AddressBook', 'Address Book', function(event) {
switch(event.status) {
case EVENT_SUCCESS:
break;
case EVENT_ERROR:
break;
}
});
As it allows callbacks to be composed more easily.
- The last argument is thus the request and clearly input.
- If multiple success handlers are needed, success could be an array of
functions (same for error handlers).
multiple handlers can be passes using a composition function:
// can be defined in the library
var all = function(flist) {
return function(event) {
for (int i = 0; i flist.length; i++) {
flist[i](event);
}
};
};
indexedDB.open('AddressBook', 'Address Book', all([fn1, fn2, fn3]));
Cheers,
Keean.
- I would eliminiate readyState and move abort() to IDBEvent (=output and
an interface to the DB client).
- With subclasses of IDBEvent one has the choice of eliminating them by
making their fields additional parameters of success() and error().
event.result is a prime candidate for this!
- This above way eliminates the need of manipulating the request *after* (a
reference to) it has been placed in the event queue.
Questions:
- Is it really necessary to make IDBEvent a subclass of Event and thus drag
the DOM (which seems to be universally hated) into IndexedDB?
- Are there any other asynchronous DB APIs for dynamic languages that one
could learn from (especially from mistakes that they have made)? They must
have design principles and rationales one might be able to use. WebDatabase
(minus schema plus cursor) looks nice.
On Jan 10, 2011, at 23:40 , Keean Schupke wrote:
Hi,
I did say it was for fun! If you think it should be suggested somewhere I
am happy to do so. Note that I renamed 'onsuccess' to 'bind' to show how it
works as a monad, there is no need to do this (although I prefer to it to
explicitly show it is a Monad).
The definition of unit is simply:
var unit = function(v) {
return {
onsuccess: function(f) {f(v);}
};
};
And then you can compose callbacks using 'onsuccess'...
you might like to keep onsuccess, and use result instead of unit... So
simply using the above definition you can compose callbacks:
var y =
db.transaction([foo]).objectStore(foo).getM(mykey1).onsuccess(function(result1)
{
db.transaction([foo]).objectStore(foo).getM(mykey2).onsuccess(function(result2)
{
result(result1 + result2);
});
});
Cheers,
Keean.
On 10 January 2011 22:31, Jonas Sicking jo...@sicking.cc wrote:
This seems like something better suggeseted to the lists at ECMA where
javascript (or rather ECMAScript) is being standardized. I hardly
think that a database API like indexedDB is the place to redefine how
javascript should handle asynchronous programming.
/ Jonas
On Mon, Jan 10, 2011 at 2:26 PM, Keean Schupke ke...@fry-it.com wrote:
Just to correct my cut and paste error, that was of course supposed to
be:
var y = do {
result1 - db.transaction([foo]).objectStore(foo).getM(mykey1);
result2 - db.transaction([foo]).objectStore(foo).getM(mykey2);
unit(result1 + result2);
}
Cheers,
Keean.
On 10 January 2011 22:24, Keean Schupke ke...@fry-it.com wrote:
Okay, sorry, the original change seemed sensible, I guess I didn't see
how
you got from there to promises.
Here's some fun to think about as an alternative though:
Interestingly the pattern of multiple callbacks, providing each
callback
is passed zero or one parameter forms a Monad.
So for example if 'unit' is the constructor for the object returned
from
get then onsuccess it 'bind' and I can show that these obey the 3
monad
laws. Allowing composability of callbacks. So you effectively have:
var x = db.transaction([foo]).objectStore(foo).getM(mykey);
var y =
db.transaction([foo]).objectStore(foo).getM(mykey1).bind(function(result1)
{
db.transaction([foo]).objectStore(foo).getM(mykey2).bind(function(result2)
{
unit(result1 + result2);
});
});
The two objects returned x and y are both the same kind of object.
y
represents the sum or concatination of the results of the lookups
mykey1
and mykey2. You would use it identically to using the result of a
single
lookup:
x.bind(function(result) {... display the result of a single lookup
...});
y.bind(function(result) {... display the result of both lookups ...});
If we could then have some syntactic
Re: [IndexedDB] Events and requests
Looks great, I just tried to stay as close to the current API as possible.
A single handler should definitely be enough. Can, say, a cursor be read
multiple times (if there are several success handlers)? Doesn’t that make
things more complicated?
On Jan 11, 2011, at 10:22 , Keean Schupke wrote:
Comments inline:
On 11 January 2011 07:11, Axel Rauschmayer a...@rauschma.de wrote:
Coming back to the initial message in this thread (at the very bottom):
= General rule of thumb: clearly separate input data and output data.
Using JavaScript dynamic nature, things could look as follows:
indexedDB.open('AddressBook', 'Address Book', {
success: function(evt) {
},
error: function(evt) {
}
});
Personally I prefer a single callback passed an object.
indexedDB.open('AddressBook', 'Address Book', function(event) {
switch(event.status) {
case EVENT_SUCCESS:
break;
case EVENT_ERROR:
break;
}
});
As it allows callbacks to be composed more easily.
- The last argument is thus the request and clearly input.
- If multiple success handlers are needed, success could be an array of
functions (same for error handlers).
multiple handlers can be passes using a composition function:
// can be defined in the library
var all = function(flist) {
return function(event) {
for (int i = 0; i flist.length; i++) {
flist[i](event);
}
};
};
indexedDB.open('AddressBook', 'Address Book', all([fn1, fn2, fn3]));
Cheers,
Keean.
- I would eliminiate readyState and move abort() to IDBEvent (=output and an
interface to the DB client).
- With subclasses of IDBEvent one has the choice of eliminating them by
making their fields additional parameters of success() and error().
event.result is a prime candidate for this!
- This above way eliminates the need of manipulating the request *after* (a
reference to) it has been placed in the event queue.
Questions:
- Is it really necessary to make IDBEvent a subclass of Event and thus drag
the DOM (which seems to be universally hated) into IndexedDB?
- Are there any other asynchronous DB APIs for dynamic languages that one
could learn from (especially from mistakes that they have made)? They must
have design principles and rationales one might be able to use. WebDatabase
(minus schema plus cursor) looks nice.
On Jan 10, 2011, at 23:40 , Keean Schupke wrote:
Hi,
I did say it was for fun! If you think it should be suggested somewhere I
am happy to do so. Note that I renamed 'onsuccess' to 'bind' to show how it
works as a monad, there is no need to do this (although I prefer to it to
explicitly show it is a Monad).
The definition of unit is simply:
var unit = function(v) {
return {
onsuccess: function(f) {f(v);}
};
};
And then you can compose callbacks using 'onsuccess'...
you might like to keep onsuccess, and use result instead of unit... So
simply using the above definition you can compose callbacks:
var y =
db.transaction([foo]).objectStore(foo).getM(mykey1).onsuccess(function(result1)
{
db.transaction([foo]).objectStore(foo).getM(mykey2).onsuccess(function(result2)
{
result(result1 + result2);
});
});
Cheers,
Keean.
On 10 January 2011 22:31, Jonas Sicking jo...@sicking.cc wrote:
This seems like something better suggeseted to the lists at ECMA where
javascript (or rather ECMAScript) is being standardized. I hardly
think that a database API like indexedDB is the place to redefine how
javascript should handle asynchronous programming.
/ Jonas
On Mon, Jan 10, 2011 at 2:26 PM, Keean Schupke ke...@fry-it.com wrote:
Just to correct my cut and paste error, that was of course supposed to be:
var y = do {
result1 - db.transaction([foo]).objectStore(foo).getM(mykey1);
result2 - db.transaction([foo]).objectStore(foo).getM(mykey2);
unit(result1 + result2);
}
Cheers,
Keean.
On 10 January 2011 22:24, Keean Schupke ke...@fry-it.com wrote:
Okay, sorry, the original change seemed sensible, I guess I didn't see how
you got from there to promises.
Here's some fun to think about as an alternative though:
Interestingly the pattern of multiple callbacks, providing each callback
is passed zero or one parameter forms a Monad.
So for example if 'unit' is the constructor for the object returned from
get then onsuccess it 'bind' and I can show that these obey the 3 monad
laws. Allowing composability of callbacks. So you effectively have:
var x = db.transaction([foo]).objectStore(foo).getM(mykey);
var y =
db.transaction([foo]).objectStore(foo).getM(mykey1).bind(function(result1)
{
db.transaction([foo]).objectStore(foo).getM(mykey2).bind(function(result2)
{
unit(result1 + result2);
});
});
The two objects returned x and y are both the same
Re: [IndexedDB] Events and requests
If one handler changes the state who knows what will happen. I guess the
order in which handers are called is significant. That's one advantage to
using a function like all to compose callbacks - its very clear what order
they get called in. You could call it 'sequence' to make it even clearer
(that they are called one at a time left to right, not in parallel).
You could make the callback an optional parameter, and use it if supplied,
and return an object (for the existing API if none is supplied).
Cheers,
Keean.
On 11 January 2011 09:31, Axel Rauschmayer a...@rauschma.de wrote:
Looks great, I just tried to stay as close to the current API as possible.
A single handler should definitely be enough. Can, say, a cursor be read
multiple times (if there are several success handlers)? Doesn’t that make
things more complicated?
On Jan 11, 2011, at 10:22 , Keean Schupke wrote:
Comments inline:
On 11 January 2011 07:11, Axel Rauschmayer a...@rauschma.de wrote:
Coming back to the initial message in this thread (at the very bottom):
= General rule of thumb: clearly separate input data and output data.
Using JavaScript dynamic nature, things could look as follows:
indexedDB.open('AddressBook', 'Address Book', {
success: function(evt) {
},
error: function(evt) {
}
});
Personally I prefer a single callback passed an object.
indexedDB.open('AddressBook', 'Address Book', function(event) {
switch(event.status) {
case EVENT_SUCCESS:
break;
case EVENT_ERROR:
break;
}
});
As it allows callbacks to be composed more easily.
- The last argument is thus the request and clearly input.
- If multiple success handlers are needed, success could be an array of
functions (same for error handlers).
multiple handlers can be passes using a composition function:
// can be defined in the library
var all = function(flist) {
return function(event) {
for (int i = 0; i flist.length; i++) {
flist[i](event);
}
};
};
indexedDB.open('AddressBook', 'Address Book', all([fn1, fn2, fn3]));
Cheers,
Keean.
- I would eliminiate readyState and move abort() to IDBEvent (=output and
an interface to the DB client).
- With subclasses of IDBEvent one has the choice of eliminating them by
making their fields additional parameters of success() and error().
event.result is a prime candidate for this!
- This above way eliminates the need of manipulating the request *after*
(a reference to) it has been placed in the event queue.
Questions:
- Is it really necessary to make IDBEvent a subclass of Event and thus
drag the DOM (which seems to be universally hated) into IndexedDB?
- Are there any other asynchronous DB APIs for dynamic languages that one
could learn from (especially from mistakes that they have made)? They must
have design principles and rationales one might be able to use. WebDatabase
(minus schema plus cursor) looks nice.
On Jan 10, 2011, at 23:40 , Keean Schupke wrote:
Hi,
I did say it was for fun! If you think it should be suggested somewhere I
am happy to do so. Note that I renamed 'onsuccess' to 'bind' to show how it
works as a monad, there is no need to do this (although I prefer to it to
explicitly show it is a Monad).
The definition of unit is simply:
var unit = function(v) {
return {
onsuccess: function(f) {f(v);}
};
};
And then you can compose callbacks using 'onsuccess'...
you might like to keep onsuccess, and use result instead of unit... So
simply using the above definition you can compose callbacks:
var y =
db.transaction([foo]).objectStore(foo).getM(mykey1).onsuccess(function(result1)
{
db.transaction([foo]).objectStore(foo).getM(mykey2).onsuccess(function(result2)
{
result(result1 + result2);
});
});
Cheers,
Keean.
On 10 January 2011 22:31, Jonas Sicking jo...@sicking.cc wrote:
This seems like something better suggeseted to the lists at ECMA where
javascript (or rather ECMAScript) is being standardized. I hardly
think that a database API like indexedDB is the place to redefine how
javascript should handle asynchronous programming.
/ Jonas
On Mon, Jan 10, 2011 at 2:26 PM, Keean Schupke ke...@fry-it.com wrote:
Just to correct my cut and paste error, that was of course supposed to
be:
var y = do {
result1 - db.transaction([foo]).objectStore(foo).getM(mykey1);
result2 - db.transaction([foo]).objectStore(foo).getM(mykey2);
unit(result1 + result2);
}
Cheers,
Keean.
On 10 January 2011 22:24, Keean Schupke ke...@fry-it.com wrote:
Okay, sorry, the original change seemed sensible, I guess I didn't see
how
you got from there to promises.
Here's some fun to think about as an alternative though:
Interestingly the pattern of multiple callbacks, providing each
callback
is passed zero or one parameter forms a Monad.
So for example
Re: [Bug 11398] New: [IndexedDB] Methods that take multiple optional parameters should instead take an options object
On Mon, Jan 10, 2011 at 9:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Dec 14, 2010 at 12:13 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Dec 14, 2010 at 7:50 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Dec 14, 2010 at 8:47 AM, Jeremy Orlow jor...@chromium.org wrote: Btw, I forgot to mention IDBDatabase.transaction which I definitely think should take an options object as well. Hmm.. I think we should make the first argument required, I actually thought it was until I looked just now. I don't see what the use case is for opening all tables. FWIW I'm finding that the majority of the IndexedDB code I read and write does indeed need to lock everything. I'm also finding that most of the code I'm writing/reading won't be helped at all by defaulting to READ_ONLY... In fact, it seems rather harmful that the syntax which will result in more lock contention is simpler than the syntax which is better optimized. But you're right about this. So, if we're trying to force users to write highly parallelizable code, then yes the first arg probably should be required. But if we're trying to make IndexedDB easy to use then actually the mode should probably be changed back to defaulting to READ_WRITE. I know I argued for the mode default change earlier, but I'm having second thoughts. We've spent so much effort making the rest of the API easy to use that having points of abrasion like this seem a bit wrong. Especially if (at least in my experience) the abrasion is only going to help a limited number of cases--and probably ones where the developers will pay attention to this without us being heavy-handed. I think ease of use is different from few characters typed. For example it's important that the API discourages bugs, for example by making the code easy and clear to read. Included in that is IMHO to make it easy to make the code fast. It won't make the cost fast. It'll make it'll allow parallel execution. Which will only matter if a developer is trying to do multiple reads at once and you have significant latency to your backend and/or it's heavily disk bound. Which will only be true in complex web apps--the kind where a developer is going to be more conscious of various performance bottlenecks. In other words, most of the time, defaulting to READ_ONLY will almost certainly have no visible impact in speed. I'm pretty sure this is decreasing ease of use any way you measure it. And that's mostly based on me personally having spent several days coding up stuff with IndexedDB + talking to others who have doen the same. J
[Bug 11730] Please enter your feedback, carefully indicating the title of the section for which you are submitting feedback, quoting the text that's wrong today if appropriate. If you're suggesting
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11730 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID --- Comment #1 from Art Barstow art.bars...@nokia.com 2011-01-11 11:31:57 UTC --- This is not an invalid bug report (not a bug). -- 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: [chromium-html5] LocalStorage inside Worker
So what's the plan for localStorage in workers? J On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke ke...@fry-it.com wrote: I think I already came to the same conclusion... JavaScript has no control over effects, which devalues STM. In the absence of effect control, apparent serialisation (of transactions) is the best you can do. What we need is a purely functional JavaScript, it makes threading so much easier ;-) Cheers, Keean. On 10 January 2011 23:42, Robert O'Callahan rob...@ocallahan.org wrote: STM is not a panacea. Read http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspxif you haven't already. In Haskell, where you have powerful control over effects, it may work well, but Javascript isn't anything like that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Last Call for Navigation Timing API
This is a Last Call transition announcement for Navigation Timing: http://www.w3.org/TR/2011/WD-navigation-timing-20110111/ Please send comments to public-web-p...@w3.org with [NavigationTiming] at the start of the subject line by 8 February 2011. Note: Feedback would be especially appreciated regarding the use of window.performance attribute and the potential to conflict with existing Web pages. See also the thread at [1]. We would especially appreciate feedback from the Web Application Working Group, due to the use of WebIDL in the document. Thank you, Philippe [1] http://lists.w3.org/Archives/Public/public-web-perf/2010Dec/0027.html
[Bug 11581] Is there really need to drop http compability ? This will cause lot of troubles in some http-servers and browsers. This will force developers to use ugly hacks like flash/java based impl
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11581 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||INVALID --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-01-11 19:39:26 UTC --- The protocol is no longer defined in this spec; it's defined by the hybi working group at the IETF. -- 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.
[Bug 11589] It is said that Values can be any data type supported by the structured clone algorithm, but the algorithm is not described. In fact is it deeply buried in the HTML5 specification, ope
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11589 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-01-11 19:57:23 UTC --- Web Storage and HTML are the same spec: http://whatwg.org/C They're just split out for W3C editorial purposes. Anyway, I've added references to the HTML spec from the Web Storage spec to resolve this. open to fuzzy interpretations What is fuzzy about the structured clone spec? It should be pretty specific. -- 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.
[Bug 11606] wanted: awareness of non-persistent web storage
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11606 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-01-11 20:15:21 UTC --- Given that such features are generally implemented for users with, shall we say, a more emphatic belief in privacy, it seems likely that they would also not want sites to be able to tell if storage was disabled. It seems reasonable for the UA to remind the user though (this site is storing data, be aware that it will be blown away when you close the browser or some such). But that's out of scope for the spec. -- 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: [chromium-html5] LocalStorage inside Worker
With localStorage being the way it is, I personally don't think we can ever allow localStorage access in workers. However I do think we can and should provide access to a separate storage area (or several named storage areas) which can only be accessed from callbacks. On the main thread those callbacks would be asynchronous. In workers those callbacks can be either synchronous or asynchronous. Here is the API I'm proposing: getNamedStorage(in DOMString name, in Function callback); getNamedStorageSync(in DOMString name, in Function callback); The latter is only available in workers. The former is available in both workers and in windows. When the callback is called it's given a reference to the Storage object which has the exact same API as localStorage does. Also, you're not allowed to nest getNamedStorageSync and/or IDBDatabaseSync.transaction calls. This has the added advantage that it's much more implementable without threading hazards than localStorage already is. / Jonas On Tue, Jan 11, 2011 at 6:40 AM, Jeremy Orlow jor...@chromium.org wrote: So what's the plan for localStorage in workers? J On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke ke...@fry-it.com wrote: I think I already came to the same conclusion... JavaScript has no control over effects, which devalues STM. In the absence of effect control, apparent serialisation (of transactions) is the best you can do. What we need is a purely functional JavaScript, it makes threading so much easier ;-) Cheers, Keean. On 10 January 2011 23:42, Robert O'Callahan rob...@ocallahan.org wrote: STM is not a panacea. Read http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx if you haven't already. In Haskell, where you have powerful control over effects, it may work well, but Javascript isn't anything like that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [chromium-html5] LocalStorage inside Worker
Would each 'name' storage have its own thread to improve parallelism?
would:
withNamedStorage('x', function(store) {...});
make more sense from a naming point of view?
Cheers,
Keean.
On 11 January 2011 20:58, Jonas Sicking jo...@sicking.cc wrote:
With localStorage being the way it is, I personally don't think we can
ever allow localStorage access in workers.
However I do think we can and should provide access to a separate
storage area (or several named storage areas) which can only be
accessed from callbacks. On the main thread those callbacks would be
asynchronous. In workers those callbacks can be either synchronous or
asynchronous. Here is the API I'm proposing:
getNamedStorage(in DOMString name, in Function callback);
getNamedStorageSync(in DOMString name, in Function callback);
The latter is only available in workers. The former is available in
both workers and in windows. When the callback is called it's given a
reference to the Storage object which has the exact same API as
localStorage does.
Also, you're not allowed to nest getNamedStorageSync and/or
IDBDatabaseSync.transaction calls.
This has the added advantage that it's much more implementable without
threading hazards than localStorage already is.
/ Jonas
On Tue, Jan 11, 2011 at 6:40 AM, Jeremy Orlow jor...@chromium.org wrote:
So what's the plan for localStorage in workers?
J
On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke ke...@fry-it.com wrote:
I think I already came to the same conclusion... JavaScript has no
control
over effects, which devalues STM. In the absence of effect control,
apparent
serialisation (of transactions) is the best you can do.
What we need is a purely functional JavaScript, it makes threading so
much
easier ;-)
Cheers,
Keean.
On 10 January 2011 23:42, Robert O'Callahan rob...@ocallahan.org
wrote:
STM is not a panacea. Read
http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx
if you haven't already.
In Haskell, where you have powerful control over effects, it may work
well, but Javascript isn't anything like that.
Rob
--
Now the Bereans were of more noble character than the Thessalonians,
for
they received the message with great eagerness and examined the
Scriptures
every day to see if what Paul said was true. [Acts 17:11]
Re: file-system-api: filename restrictions
Glenn: Sorry about the slow response; I was on vacation, and am only now catching up. We've discussed these issues before, see http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0229.html for much of the initial discussion. However, you've brought up a new point that I think is worth addressing. On Sun, Dec 19, 2010 at 11:26 AM, Glenn Maynard gl...@zewt.org wrote: Section 8 Uniformity of interface will cause headaches for some use cases. For example, an application may want to allow the user to fill a directory with images, then output a thumbnail of each image x.jpg into a subdirectory with the same filename, thumbs/x.jpg. However, we're forbidden from creating a new file with invalid filenames, even if they exist elsewhere. The operation will fail, and we'll have to tell our Linux users with images named at the beach: moon rock?.jpg that they have to obey Windows filename conventions--which will probably be upsetting. It'd also be a difficult rule for users to follow; while it's easy in Windows since it's globally enforced in all applications, Linux users would have to memorize the rules themselves. Actually, it's not just that Linux users now have to worry about Windows rules; Windows users also have to worry about Linux rules, in particular the path length limitation, which is 255 bytes on Linux but 255 UTF-16 code points on Windows. It's also a pain for backing up files, eg. copying moon rock?.jpg to moon rock?.jpg~, and for safe writes, writing to moon rock?.jpg.new and then renaming the finished file over the original. These seem like bigger problems than the one it's trying to solve. Is it really insufficient for these rules to define what filenames must be supported, that any others may not be, and to suggest a UA log if nonportable filenames are created? (Of all filename issues, the only one that I've ever found to be a serious real-world portability issue is case-insensitivity.) Yes, I believe that's insufficient. We've discussed this before, and 1) We really do want a fully-portable subset to be the standard; code should work everywhere if it works anywhere. You shouldn't have to code to OSX any more than you should have to code to Opera--just code to the web platform. 2) Developers often don't read UA logs. We should fail early on the dev box, rather than failing later on the user's machine. I guess there are other issues with reading data created outside of the API: - filenames that can't be decoded to a DOMString, eg. undecodable bytes in a UTF-8 filesystem. This is common in Linux after eg. unzipping a ZIP containing SJIS filenames. Should these simply be ignored with a log? I'm looking into the encoding problems now, and will respond later. In general we should be able to read any such file already, at the very least by enumerating the directory to get the FileEntry, but creating files with valid names may be tricky. - existing filenames that differ only by case. Similarly, should the UA just ignore all but one of them and make a log to the console? There's no problem accessing those through directory enumeration, or via a supplied path. You just can't create this situation using the API. Should whitespace in section 8.3 simply indicate space, U+0020? It looks like it should; my mistake. Thanks! Windows does allow creating filenames ending with NBSP and other Unicode whitespace characters, and it's not clear whether this should be allowed. Other whitespace (\r, \n, \t) is covered by the control character rule. Sorry if this is a rehash of past topics. The API is designed as it is to support a couple of different situations, only one of which is currently specced, but both of which have been discussed. What's specced so far is a per-origin sandbox that web apps can use for client-side storage. Depending on the UA's implementation of it, it's possible that the files stored there will be exposed to the host machine and potentially shared with apps outside of the browser, but we generally expect the browser to create most or all of them. Thus it makes sense to take a least-common-denominator [LCD] approach, so that code that works on any platform works on all platforms. If other apps create files there we should be able to access them no matter what, but things will go more smoothly if said apps respect our restrictions. However, an obvious expansion of this API which we've talked a lot about is the ability to expose other mount points to the browser. For example, a trusted app might be granted access to My Photos or another similar directory. There the majority of the files are expected to be created by apps outside of the browser, and you run into the thumbnail problem you describe above, where a read-modify-write of a path or even a copy operation can inadvertently create a file path that's banned by the API, but is legal on the host system. In a perfect world, I think we'd want all paths that came from
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke ke...@fry-it.com wrote:
Would each 'name' storage have its own thread to improve parallelism?
Your vocabulary is a bit off since from an API point of view, storage
areas don't have threads, the execution environments in workers and
windows do.
But if your question is weather one worker can open the storage named
foo, while another window or worker is holding the storage named
bar open, then the answer is yes.
would:
withNamedStorage('x', function(store) {...});
make more sense from a naming point of view?
I have a different association for 'with', especially in context of
JavaScript, so I prefer 'get'. But others feel free to express an
opinion.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke ke...@fry-it.com wrote:
would:
withNamedStorage('x', function(store) {...});
make more sense from a naming point of view?
I have a different association for 'with', especially in context of
JavaScript, so I prefer 'get'. But others feel free to express an
opinion.
In the context of other languages with similar constructs (request a
resource which is available within the body of the construct), the
with[resource] naming scheme is pretty common and well-known. I
personally like it.
~TJ
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 9:02 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Python has its with keyword, used like with file = open('foo'):
doStuffToTheFile(file), which similarly creates a named resource and
(with open('foo') as file:)
takes a chunk of code within which the resource is available. I know
that other languages have similar, but off the top of my head I'm
having trouble thinking of them.
For what it's worth, my first reaction to withNamedStorage was that
it felt like the vocabulary of another language transplanted into
Javascript, and that it felt out of place.
That may be due to there being no comparable APIs like this in
Javascript yet (that I can think of) rather than the vocabulary
describing it, though.
--
Glenn Maynard
