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 wrote: > On Tue, Jan 11, 2011 at 1:02 PM, Glenn Maynard 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 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 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 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 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 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 res
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 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 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 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 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).b
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 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 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 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 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 wrote:
>>> >>
>>> >> Okay, sorry, the original change seemed sensible, I guess I didn't see
>>> how
>>> >> you got
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 wrote: > On Tue, Dec 14, 2010 at 12:13 PM, Jeremy Orlow > wrote: > > > > On Tue, Dec 14, 2010 at 7:50 PM, Jonas Sicking wrote: > >> > >> On Tue, Dec 14, 2010 at 8:47 AM, Jeremy Orlow > 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 changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID --- Comment #1 from Art Barstow 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 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 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: [chromium-html5] LocalStorage inside Worker
Allow access only from serialized callbacks in workers. Cheers Keean On 11 Jan 2011 14:45, "Jeremy Orlow" wrote: > So what's the plan for localStorage in workers? > > J > > On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke 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 wrote: >> >>> STM is not a panacea. Read >>> http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspxifyou 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] >>> >> >>
[Bug 11570] Can't find the posibility for user authentication by connecting to a websocket! Missing?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11570 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WONTFIX --- Comment #2 from Ian 'Hixie' Hickson 2011-01-11 19:21:27 UTC --- Indeed. -- 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.
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 changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||INVALID --- Comment #1 from Ian 'Hixie' Hickson 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson 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 changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WONTFIX
--- Comment #1 from Ian 'Hixie' Hickson 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 wrote: > So what's the plan for localStorage in workers? > J > > On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke 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 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 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 wrote:
> > So what's the plan for localStorage in workers?
> > J
> >
> > On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke 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
> 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 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 worl
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke 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 wrote:
> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke 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 3:58 PM, Jonas Sicking wrote: > With localStorage being the way it is, I personally don't think we can > ever allow localStorage access in workers. This makes sense if the storage mutex goes away entirely for localStorage itself (reflecting current implementations). If localStorage retains the current unimplemented locking, then it makes sense to use the same Storage for both APIs. The async callback would use the same storage mutex, so a fully compliant implementation would be threadsafe. Removing it makes sense to me, though. > 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); I guess to determine whether a particular named storage is supported, you'd call it with the name and an empty callback; if the name isn't supported, it raises an exception. A little awkward, but reasonable. Maybe the specs guarantee this in general for async callbacks, but getNamedStorage should never run callback immediately before returning, even if the lock is available; always wait for the script to return, as if the lock was taken. > 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. StorageEvent would need an additional attribute, containing the name associated with the storageArea it's been given. That's because you can no longer say eg. "event.storageArea == window.localStorage" to determine which Storage triggered the event. Other than that, the storage event is straightforward; when called during a storage callback, it has access to the locked Storage object via storageArea. > Also, you're not allowed to nest getNamedStorageSync and/or > IDBDatabaseSync.transaction calls. If a single mutex is used for all storage objects, then nesting getNamedStorageSync with itself is safe. If separate mutexes are used for each storage object, then it's still okay to nest getNamedStorageSync calls to the same object. This essentially makes it act like a recursive mutex, which can be very convenient. It reduces how much a function has to care about its caller; your Javascript function doesn't need to specify "must not be called from a getNamedStorageSync callback" if it uses that function itself. One other thing to consider: releasing the Storage object and continuing execution. The minimum delays imposed on timers makes setTimeout(continueFunction, 0) a poor solution. On Tue, Jan 11, 2011 at 5:11 PM, Keean Schupke wrote: > Would each 'name' storage have its own thread to improve parallelism? Callbacks would execute in the thread they were queued from, not in a separate thread, if that's what you mean. -- Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 2:44 PM, Tab Atkins Jr. wrote:
> On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking wrote:
>> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke 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.
Even for asynchronous callbacks? Can you give any examples?
/ Jonas
Re: file-system-api: filename restrictions
On Tue, Jan 11, 2011 at 5:33 PM, Eric Uhrhane wrote: > 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 I just lack sympathy for developers who completely ignore browser warnings.) >> - 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. It could happen if the user's locale changes, but that's not a likely problem. The infamous Turkish "I" comes to mind as a portability problem: code could reasonably create "Info" in one place and read it as "info" in another, which would be different files in a Turkish locale. Windows still treats "I" and "i" as the same letter even in Turkish codepages, but a Linux glibc-based implementation wouldn't. Should the usual equivalences for the ASCII range be required, regardless of the user's locale? > 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 the web > app to be LCD-safe, but all paths that came from the host machine to > be permitted. Since that's not generally detectable by the UA, or > even well-defined in all cases, perhaps we can help developers to > solve the problem manually. We could offer another API [or just a > flag in the existing APIs] that says "I'm using paths derived from the > local system. Let me try this, even if it's not LCD-safe]." I don't > think we want to allow that in the per-origin sandbox defined in the > current spec, but I could see it being quite valuable for other mount > points. If that sounds reasonable, we can put that in when we spec > this potential future API expansion. Letting the user grant access to specific directories is in my opinion the one big missing piece that will make this API very interesting. That's also when this will all become much more important, so leaving these to be addressed together seems fine. -- Glenn Maynard
Re: file-system-api: filename restrictions
On 1/11/11 8:02 PM, Glenn Maynard wrote: The infamous Turkish "I" comes to mind as a portability problem: code could reasonably create "Info" in one place and read it as "info" in another, which would be different files in a Turkish locale. Windows still treats "I" and "i" as the same letter even in Turkish codepages, but a Linux glibc-based implementation wouldn't. For what it's worth. HTML5 typically uses "ASCII case-insensitivity" to avoid this problem. But they're working with strings that are mostly ASCII, which may not be the case for filenames -Boris
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 4:39 PM, Jonas Sicking wrote:
> On Tue, Jan 11, 2011 at 2:44 PM, Tab Atkins Jr. wrote:
>> On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking wrote:
>>> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke 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.
>
> Even for asynchronous callbacks? Can you give any examples?
Not *quite* asynchronous callbacks (that's something fairly specific
to languages that run on an event loop), but close enough.
Lisp has, for example, macros like WITH-HASH-TABLE-ITERATOR, which
takes a hash, a name for the iterator to be produced, and then a chunk
of code within which the iterator is available.
Python has its "with" keyword, used like "with file = open('foo'):
doStuffToTheFile(file)", which similarly creates a named resource and
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.
~TJ
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 9:02 PM, Tab Atkins Jr. 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
Re: WebSocket question
Now that there's ArrayBuffer will a binary protocol be added? https://developer.mozilla.org/en/JavaScript_typed_arrays/ArrayBuffer Just need to say you're using the binary protocol in the handshake. Don't need length or anything since it would just be a normal TCP stream and someone could create their own sub protocol. Been waiting for a binary protocol for a while for games. Send would just accept an ArrayBuffer and treat it like an Uint8Array probably. If you said you were using a binary protocol then the onmessage event.data would just be an ArrayBuffer object. Simple. Please don't make it complicated. Don't be like "but people will get confused when their long messages are split between multiple onmessage callbacks." It should just be a pure TCP stream with no special stuff. That is you could get any amount of bytes during a receive just like regular TCP where anything over the MTU is chopped up.
[Bug 11740] New: vbvbcb dcbd fhfdh h hfgh fg h fgh hfg hfghfg hf
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11740 Summary: vbvbcb dcbd fhfdh h hfgh fg h fgh hfg hfghfg hf Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/webstorage/ Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#top Comment: vbvbcb dcbd fhfdh h hfgh fg h fgh hfg hfghfg hf Posted from: 120.72.93.170 -- 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
On Tue, Jan 11, 2011 at 6:02 PM, Tab Atkins Jr. wrote:
> On Tue, Jan 11, 2011 at 4:39 PM, Jonas Sicking wrote:
>> On Tue, Jan 11, 2011 at 2:44 PM, Tab Atkins Jr. wrote:
>>> On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking wrote:
On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke 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.
>>
>> Even for asynchronous callbacks? Can you give any examples?
>
> Not *quite* asynchronous callbacks (that's something fairly specific
> to languages that run on an event loop), but close enough.
>
> Lisp has, for example, macros like WITH-HASH-TABLE-ITERATOR, which
> takes a hash, a name for the iterator to be produced, and then a chunk
> of code within which the iterator is available.
>
> Python has its "with" keyword, used like "with file = open('foo'):
> doStuffToTheFile(file)", which similarly creates a named resource and
> 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.
All of these seem very similar to the 'with' operator in javascript,
but quite different from a function which registers a asynchronous
callback.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
The callback is doing something 'with' the resource you are waiting for. The
callback cannot be called 'without' the resource being available. The 'with'
refers to the 'named storage object' not the registration of the callback.
"with" this named storage object "do" function
Would be how I read it.
Cheers,
Keean.
On 12 January 2011 07:48, Jonas Sicking wrote:
> On Tue, Jan 11, 2011 at 6:02 PM, Tab Atkins Jr.
> wrote:
> > On Tue, Jan 11, 2011 at 4:39 PM, Jonas Sicking wrote:
> >> On Tue, Jan 11, 2011 at 2:44 PM, Tab Atkins Jr.
> wrote:
> >>> On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking
> wrote:
> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke
> 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.
> >>
> >> Even for asynchronous callbacks? Can you give any examples?
> >
> > Not *quite* asynchronous callbacks (that's something fairly specific
> > to languages that run on an event loop), but close enough.
> >
> > Lisp has, for example, macros like WITH-HASH-TABLE-ITERATOR, which
> > takes a hash, a name for the iterator to be produced, and then a chunk
> > of code within which the iterator is available.
> >
> > Python has its "with" keyword, used like "with file = open('foo'):
> > doStuffToTheFile(file)", which similarly creates a named resource and
> > 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.
>
> All of these seem very similar to the 'with' operator in javascript,
> but quite different from a function which registers a asynchronous
> callback.
>
> / Jonas
>
Re: [chromium-html5] LocalStorage inside Worker
On 11 January 2011 22:37, Jonas Sicking wrote:
> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke 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
>
They could have, as you want to serialise access, that is equivalent to
having one thread per storage area that executes each of the callbacks from
its own event queue...
>
> 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.
>
Sure, but get for me is always in the context of getters and setters,
var x = object.getProperty();
object.setProperty(x);
Cheers,
Keean.
Re: [chromium-html5] LocalStorage inside Worker
Now I think about it I see where you were coming from with get:
var x = getNamedStorage('x');
x.onsuccess(function(store) {...});
would make more sense like that... and I guess if you include the onsuccess
callback in one function you get:
getNamedStorage('x', function(store) {...});
I reads better this morning than it did last night.
Cheers,
Keean.
On 12 January 2011 07:51, Keean Schupke wrote:
> The callback is doing something 'with' the resource you are waiting for.
> The callback cannot be called 'without' the resource being available. The
> 'with' refers to the 'named storage object' not the registration of the
> callback.
>
> "with" this named storage object "do" function
>
>
> Would be how I read it.
>
>
> Cheers,
> Keean.
>
>
> On 12 January 2011 07:48, Jonas Sicking wrote:
>
>> On Tue, Jan 11, 2011 at 6:02 PM, Tab Atkins Jr.
>> wrote:
>> > On Tue, Jan 11, 2011 at 4:39 PM, Jonas Sicking
>> wrote:
>> >> On Tue, Jan 11, 2011 at 2:44 PM, Tab Atkins Jr.
>> wrote:
>> >>> On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking
>> wrote:
>> On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke
>> 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.
>> >>
>> >> Even for asynchronous callbacks? Can you give any examples?
>> >
>> > Not *quite* asynchronous callbacks (that's something fairly specific
>> > to languages that run on an event loop), but close enough.
>> >
>> > Lisp has, for example, macros like WITH-HASH-TABLE-ITERATOR, which
>> > takes a hash, a name for the iterator to be produced, and then a chunk
>> > of code within which the iterator is available.
>> >
>> > Python has its "with" keyword, used like "with file = open('foo'):
>> > doStuffToTheFile(file)", which similarly creates a named resource and
>> > 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.
>>
>> All of these seem very similar to the 'with' operator in javascript,
>> but quite different from a function which registers a asynchronous
>> callback.
>>
>> / Jonas
>>
>
>
