el is also essential in
any kind of enterprise setting where the IT department will want to audit
and approve apps for use.
Cheers,
Keean.
On 6 February 2013 11:03, Robin Berjon wrote:
> On 06/02/2013 08:36 , Keean Schupke wrote:
>
>> I don't think you can say either an up fro
I don't think you can say either an up front dialog or popups do not work.
There are clear examples of both working, Android and iPhone respectively.
Each has a different set of trade-offs and is better in some circumstances,
worse in others.
In my opinion an API should allow for both, so that the
> solution will be ignored, nay ridiculed. If you want developers to play
> along, you've got to give them some carrot as well.
>
>
> On Sat, Feb 2, 2013 at 11:43 AM, Keean Schupke wrote:
>
>> There are benefits to the user, in that it allows all permissions to be
>>
to the permission
review/edit page and disabled some permissions since the app started.
Cheers,
Keean.
Cheers,
Keean.
On 2 Feb 2013 10:27, "Florian Bösch" wrote:
> On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke wrote:
>
>> I think a static declaration is better for securi
ives the set of permissions he'll need from
> the set of permissions his frameworks/libraries advise. Which would favor a
> permission API. On the other hand most developers would probably be happy
> to state permissions once for the page, and the markup could just be a
> "remote-
I would like the permissions to be changeable. Not a one time dialog that
appears and irrevocably commits me to my choices, but a page with
enable/disable toggles I can return and review the permissions and change
at any time.
How about instead of a request API the required permissions are in tags
On 1 June 2011 01:37, Pablo Castro wrote:
>
> -Original Message-
> From: simetri...@gmail.com [mailto:simetri...@gmail.com] On Behalf Of
> Aryeh Gregor
> Sent: Tuesday, May 31, 2011 3:49 PM
>
> >> On Tue, May 31, 2011 at 6:39 PM, Pablo Castro
> >> wrote:
> >> > No, that was poor wording
On 6 May 2011 10:18, Jonas Sicking wrote:
> On Thu, May 5, 2011 at 11:36 PM, Keean Schupke wrote:
> > On 6 May 2011 03:00, Jonas Sicking wrote:
> >>
> >> On Wed, May 4, 2011 at 11:12 PM, Keean Schupke
> wrote:
> >> > On 5 May 2011 00:33, Aryeh Gr
On 6 May 2011 00:22, Aryeh Gregor wrote:
> On Thu, May 5, 2011 at 2:12 AM, Keean Schupke wrote:
> > What if the new version uses the same property name for a different
> thing?
>
> Yes, obviously it's going to be possible for code changes to cause
> hard-to-catch bu
On 6 May 2011 03:00, Jonas Sicking wrote:
> On Wed, May 4, 2011 at 11:12 PM, Keean Schupke wrote:
> > On 5 May 2011 00:33, Aryeh Gregor wrote:
> >>
> >> On Tue, May 3, 2011 at 7:57 PM, Jonas Sicking wrote:
> >> > I don't think we should do callback
rted binary collation up through version 4,
> for instance.
>
A good point about MySQL.
>
> On Wed, May 4, 2011 at 3:49 AM, Keean Schupke wrote:
> > I thought only the app that created the db could open it (for security
> > reasons)... so it becomes the app's respo
On 4 May 2011 21:01, Jonas Sicking wrote:
> On Wed, May 4, 2011 at 1:10 AM, Keean Schupke wrote:
> > On 4 May 2011 00:57, Jonas Sicking wrote:
> >>
> >> On Tue, May 3, 2011 at 12:19 AM, Keean Schupke
> wrote:
> >> > The more I think about it, t
On 4 May 2011 00:57, Jonas Sicking wrote:
> On Tue, May 3, 2011 at 12:19 AM, Keean Schupke wrote:
> > The more I think about it, the more I want a user-specified comparison
> > function. Efficiency should not be an issue here - the engines should
> tweek
> > the
On 4 May 2011 00:57, Jonas Sicking wrote:
> On Tue, May 3, 2011 at 12:19 AM, Keean Schupke wrote:
> > The more I think about it, the more I want a user-specified comparison
> > function. Efficiency should not be an issue here - the engines should
> tweek
> > the
On 3 May 2011 23:59, Aryeh Gregor wrote:
> On Tue, May 3, 2011 at 10:56 AM, Keean Schupke wrote:
> > Why does it need to be persisted? I would prefer the database to be
> > stateless. Obviously all users of the database need to use the same
> > function.
>
> And if
and kept out of individual
pages, whilst not needing to be stored in the database at all.
Cheers,
Keean.
On 3 May 2011 15:27, Aryeh Gregor wrote:
> On Tue, May 3, 2011 at 3:19 AM, Keean Schupke wrote:
> > The more I think about it, the more I want a user-specified comparison
> >
callback nor an event).
Keean.
On 2 May 2011 19:57, Aryeh Gregor wrote:
> On Fri, Apr 29, 2011 at 3:19 PM, Keean Schupke wrote:
> > As long as we have a binary mode I am happy.
>
> Something I didn't think to mention: what exactly is "binary mode" for
> DOMStrings
On Sunday, 1 May 2011, Aryeh Gregor wrote:
> On Fri, Apr 29, 2011 at 3:32 PM, Jonas Sicking wrote:
>> I agree that we will eventually want to standardize the set of allowed
>> collations. Similarly to how we'll want to standardize on one set of
>> charset encodings supported. However I don't thin
There is always something like UCA:
http://www.unicode.org/reports/tr10/
which looks interesting.
Cheers,
Keean.
On 29 April 2011 20:32, Jonas Sicking wrote:
> On Fri, Apr 29, 2011 at 12:19 PM, Keean Schupke wrote:
> > On Friday, 29 April 2011, Jonas Sicking wrote:
> >&
On Friday, 29 April 2011, Jonas Sicking wrote:
> On Fri, Apr 29, 2011 at 11:16 AM, Pablo Castro
> wrote:
>> We've had quite a bit of debate on this but I don't think we've reached
>> closure. At this point I would be fine with either one of a) postpone to v2
>> and agree that for now we'll just
On 4 April 2011 22:55, Aryeh Gregor wrote:
> On Fri, Apr 1, 2011 at 2:39 PM, Jonas Sicking wrote:
> > There are several reasons why we don't want to rely exclusively on
> > SQLite, other than solely W3C formalia.
> >
> > First of all, what should we do once the SQLite team releases a new
> > ver
On 4 April 2011 22:09, Boris Zbarsky wrote:
> On 4/4/11 9:25 AM, Keean Schupke wrote:
>
>> SQL is a standard language (or API) for talking to databases.
>>
>
> It's a family of languages/APIs, which all have slightly different
> behaviors.
>
>
> Why sho
On 4 April 2011 20:58, Jonas Sicking wrote:
> On Monday, April 4, 2011, Joran Greef wrote:
> > On 04 Apr 2011, at 7:28 PM, Mikeal Rogers wrote:
> >
> >> the biggest bottleneck here in the current implementation would be the
> transaction overhead on a database this size, which is because of
> pe
I would point out that RelationalDB is relationally complete and the api
does not depend on the sqlite spec at all.
Cheers
Keean
On Apr 1, 2011 8:58 PM, "Jonas Sicking" wrote:
> On Fri, Apr 1, 2011 at 12:39 PM, Glenn Maynard wrote:
>>> Lastly, some vendors have expressed unwillingness to embed S
On 4 April 2011 16:04, Tab Atkins Jr. wrote:
> On Mon, Apr 4, 2011 at 8:07 AM, Joran Greef wrote:
> > On 04 Apr 2011, at 4:39 PM, Jonas Sicking wrote:
> >> Hence it would still be the case that we would be relying on the
> >> SQLite developers to maintain a stable SQL interpretation...
> >
> > S
Some thoughts:
On 4 April 2011 16:10, Mikeal Rogers wrote:
> i've mostly stayed out of this thread because i felt like i'd just being
> fanning the flames but i really can't stay out anymore.
>
> databases are more that SQL, always have been.
>
> SQL is a DSL for relational database access. all
On 4 April 2011 15:55, Keean Schupke wrote:
> Yes, it already has well defined set operations. Solid is a matter of
> testing by enough people (and if you wanted to try it and feed back that
> would be a start). Fast should not be a problem, as the SQL database does
> all the h
ralised union operator.
See:
http://www.arxiv.com/pdf/cs/0501053v2
To see how Meet and Join can be used to construct each of the above
operators.
Cheers,
Keean.
On 4 April 2011 15:36, Joran Greef wrote:
> On 04 Apr 2011, at 5:26 PM, Keean Schupke wrote:
>
> > This is ignoring the possibil
This is ignoring the possibility that something like RelationalDB could be
used, where a well defined common subset of SQL can be used (and I use
well-defined in the formal sense). This would allow a relatively thin
wrapper on top of most SQL implementations and would allow SQLite (or BDB)
to be us
Pity.
Anyway RelationalDB defines its API without reference to the underlying SQL
or non-SQL database... So as a candidate for replacing WebSQL, it does not
suffer from that problem.
Cheers,
Keean.
On 2 April 2011 14:56, Glenn Maynard wrote:
> On Sat, Apr 2, 2011 at 5:24 AM, Keean Schu
On 2 April 2011 08:36, Joran Greef wrote:
> On Sat, Apr 2, 2011 at 00:42:40, Glenn Maynard wrote:
>
> > You can certainly ask if they're interested in doing so, not for "our"
> > benefit (whoever "our" means), but for the benefit of the Web as a whole,
> > and there's nothing at all rude in askin
Hi Shawn
I would be interested in this. What would need to be done to make this a
Firefox plugin? I've done XPCOM stuff before in xulrunner if that's any
help.
Cheers,
Keean
On Apr 1, 2011 6:09 PM, "Shawn Wilsher" wrote:
> On 4/1/2011 5:40 AM, Nathan Kitchen wrote:
>> Are there any browser vend
> Currently there are no APIs in JavaScript to compare strings using
specific collations
We dont actually need this, just a mapping from UTF-16 string to a
sort-score (binary blob).
Its true that downloading the collation tables might take time, so we could
just provide:
var blob = string_to_sco
On 31 March 2011 19:08, Joran Greef wrote:
> > This is painful to read. WebSQL development died because SQLite, the
> most widely-deployed database software in the world, was too good? That
> sounds like a catastrophic failure of the W3C process.
> >
> > --
> > Glenn Maynard
>
> Hear.
>
> I am
On 31 March 2011 18:36, Jeremy Orlow wrote:
> On Thu, Mar 31, 2011 at 11:24 AM, Keean Schupke wrote:
>
>> On 31 March 2011 18:17, Jeremy Orlow wrote:
>>
>>> On Thu, Mar 31, 2011 at 11:09 AM, Keean Schupke wrote:
>>>
>>>> On 31 March 2011 17:41,
On 31 March 2011 18:17, Jeremy Orlow wrote:
> On Thu, Mar 31, 2011 at 11:09 AM, Keean Schupke wrote:
>
>> On 31 March 2011 17:41, Jonas Sicking wrote:
>>
>>> On Thu, Mar 31, 2011 at 1:32 AM, Joran Greef wrote:
>>> > On 31 Mar 2011, at 9:53 AM, Jonas S
On 31 March 2011 17:41, Jonas Sicking wrote:
> On Thu, Mar 31, 2011 at 1:32 AM, Joran Greef wrote:
> > On 31 Mar 2011, at 9:53 AM, Jonas Sicking wrote:
> >
> >> I previously have asked for a detailed proposal, but so far you have
> >> not supplied one but instead keep referring to other unnamed
On 31 March 2011 17:27, Jeremy Orlow wrote:
> On Thu, Mar 31, 2011 at 5:41 AM, Joran Greef wrote:
>
>> On 31 Mar 2011, at 12:52 PM, Keean Schupke wrote:
>>
>> > I totally agree with everything so far...
>> >
>> >> 3. This requires an adjustment
What they mean is that defining a generic subset of SQL with one
implementation was considered too difficult. With more than one
implementation a common subset becomes easier for the standard writers to
extract.
With RelationalDB I have taken a completely different approach. We started
from relati
x27;t implement "date" as a supported data type.
> Was that a conscious decision, and if so what was the reasoning behind it?
>
> N
>
>
> On 31 March 2011 16:33, Keean Schupke wrote:
>
>> Have a look at my RelationalDB API
>>
>> https://github.com
Have a look at my RelationalDB API
https://github.com/keean/RelationalDB
In particular examples/candy.html
A lot of work went into the underlying concepts - Its work originally
published by myself and others at the 2004 Haskell Workshop, and follows on
from HaskellDB which was the original inspi
On 31 March 2011 12:41, Joran Greef wrote:
> On 31 Mar 2011, at 12:52 PM, Keean Schupke wrote:
>
> > I totally agree with everything so far...
> >
> >> 3. This requires an adjustment to the putObject and deleteObject
> interfaces (see previous threads).
> &
On 31 March 2011 08:38, Joran Greef wrote:
> On 31 Mar 2011, at 9:34 AM, Jeremy Orlow wrote:
>
> > We have made an effort to understand other "contributions to the field".
> >
> > I'm not convinced that these are "essential database concepts" and having
> personally spent quite some time working
I was the one that asked for callbacks.
> but what do we do if those callbacks don't
> return consistent results? Or even do evil things like modify the
> stores where data is being inserted?
If the callback maps all values to a sort-order of '1' there could only ever
be one entry in the index...
On 26 March 2011 09:50, Joran Greef wrote:
> > On 26 Mar 2011, at 10:14 AM, Nikunj Mehta wrote:
> >
> > What is the minimum that can be in IDB? I am guessing the following:
> >
> > 1. Sorted key-opaque value transactional store
> > 2. Lookup of keys by values (or parts thereof)
>
> Yes, this is w
stuff in libraries. If particular people feel strongly about
certain high-level features, then by all means include a library with those
features in your browser bundle.
Cheers,
Keean.
On 23 March 2011 01:13, Pablo Castro wrote:
>
>
> From: keean.schu...@googlemail.com [mailto:keean
IMHO not the job of Idb to store the callbacks, so I don't see this
complexity as a reason not to implement the API using callbacks. I think
having one consistent API is more important.
Specifying the collation 'name' has all the same problems as callbacks
(needs to be re-done on every page, possi
On 18 March 2011 19:29, Pablo Castro wrote:
>
> From: keean.schu...@googlemail.com [mailto:keean.schu...@googlemail.com]
> On Behalf Of Keean Schupke
> Sent: Friday, March 18, 2011 1:53 AM
>
> >> See my proposal in another thread. The basic idea is to copy BDB. Have a
See my proposal in another thread. The basic idea is to copy BDB. Have a
primary index that is based on an integer, something primitive and fast.
Allow secondary indexes which use a callback to generate a binary index key.
IDB shifts the complexity out into a library. Common use cases can be
provid
I like BDB's solution. You have one primary key you cannot mess with (say an
integer for fast comparisons) you can then add any number of secondary
indexes. With a secondary index there is a callback to generate a binary
blob that is used for indexing. The callback has access to all the fields of
t
id, I'm not understanding what your comments have to do with this
> proposal. Do you have specific concerns?
>
> J
>
>
> On Wed, Mar 9, 2011 at 12:55 AM, Keean Schupke wrote:
>
>> Getting pgsql people involved sounds a great idea. Having some more people
>&g
ow wrote:
>
> On Tue, Mar 8, 2011 at 5:55 PM, Pablo Castro
> wrote:
>
>>
>> From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
>> On Behalf Of Keean Schupke
>> Sent: Tuesday, March 08, 2011 3:03 PM
>>
>> >> No objecti
te:
> >>>
> >>> On Thu, Jan 20, 2011 at 10:12 AM, Keean Schupke
> wrote:
> >>> > Compound primary keys are commonly used afaik.
> >>>
> >>> Indeed. It's one of the common themes in the debate between natural
> >>
Actually I am not sure now if SQLite uses BDB now (they might be moving to
it though). However BDB definitely now has an SQLite-3.0 compatible API now
and supports better concurrency, as well as AES encryption. So at the moment
looks like i'm moving to using BDB instead of SQLite, (apart from when
On 8 March 2011 06:33, Joran Greef wrote:
> On 08 Mar 2011, at 7:23 AM, Dean Landolt wrote:
>
> > This doesn't seem right. Assuming your WebSQL implementation had all the
> same indexes isn't it doing pretty much the same things as using separate
> objectStores in IDB? Why would it be an order of
ing
> multiple index values for a given entry using arrays. We also need to
> add support for compound keys. But lets deal with those issues in a
> separate thread.
>
> / Jonas
>
> On Thu, Mar 3, 2011 at 1:26 AM, Keean Schupke wrote:
> > On 3 March 2011 09:15, Joran Greef
On 3 March 2011 09:15, Joran Greef wrote:
> Hi Jonas
>
> I have been trying out your suggestion of using a separate object store to
> do manual indexing (and so support compound indexes or index object
> properties with arrays as values).
>
> There are some problems with this approach:
>
> 1. It'
On 2 March 2011 12:09, Joran Greef wrote:
> On 02 Mar 2011, at 1:31 PM, Jonas Sicking wrote:
>
> > I agree that we are currently enforcing a bit of schema due to the way
> > indexes work. However I think it's a good approach for an initial
> > version of this API as it covers the most simple use
On 2 March 2011 11:31, Jonas Sicking wrote:
> On Tue, Mar 1, 2011 at 10:35 PM, Joran Greef wrote:
> > On 01 Mar 2011, at 7:27 PM, Jeremy Orlow wrote:
> >
> >> 1. Be able to put an object and pass an array of index names which must
> reference the object. This may remove the need for a complicate
If you are operating on indexes then you do not have a 'join' language as
you are operating on sets. To have a join you need to be operating on
relations. A relation is commonly visualised as a row in a table in a
relational database, With IDB this would be the union of all the
property-sets of the
confusing that you could
be looking at old data. Iterating on live data seems more consistent with
run to completion semantics.
J
On Tue, Feb 1, 2011 at 5:26 PM, Keean Schupke wrote:
>
> So whats the benefit o...
So whats the benefit of allowing a cursor to modify the data under it?
Cheers,
Keean.
On 2 February 2011 01:17, Jonas Sicking wrote:
> On Tue, Feb 1, 2011 at 4:48 PM, Keean Schupke wrote:
> > Sorry, sent that before I was finished.
> >
> > Seems prone to problems in envir
?
Cheers,
Keean.
On 2 Feb 2011 00:41, "Keean Schupke" wrote:
That seems to be different from accepted practice in databases. I
>
> On 2 Feb 2011 00:39, "ben turner" wrote:
>
> No, that idea was rejecte...
>
>
> On Tue, Feb 1, 2011 at 4:35 PM, Keean Schupke wrote:
> Surely the cursor should ...
Tue, Feb 1, 2011 at 4:35 PM, Keean Schupke wrote:
> Surely the cursor should ...
Surely the cursor should be atomic, representing the instant in time the
query executed. Any updates or deletes etc would not be visible to the
cursor, only to later queries. Then you can allow any modifications
including to keys and indexes.
Cheers,
Keean
On 2 Feb 2011 00:05, "Jeremy Orlow" wro
for a bit, I think we should just go with A.
>
> Also, I don't think we should allow primary keys to be compound. I can't
> think of much precedent in other databases and it'd make things
considerably
> more complicated for no great benefit.
>
> J
>
>
> On Thu,
eremy Orlow" wrote:
> Ok. So what's the resolution? Let's bug it!
>
> On Fri, Dec 10, 2010 at 12:34 PM, Jeremy Orlow
wrote:
>
>> Any other thoughts on this issue?
>>
>>
>> On Thu, Dec 2, 2010 at 7:19 AM, Keean Schupke wrote:
>>
>>>
On 12 January 2011 11:29, Jeremy Orlow wrote:
> On Wed, Jan 12, 2011 at 11:14 AM, Glenn Maynard wrote:
>
>> On Wed, Jan 12, 2011 at 6:00 AM, Keean Schupke wrote:
>> > IMHO, if the global lock on localStorage implemented, then I think it is
>> > acceptabl
hout
>> 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
re) {...});
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 availa
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&#
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&#x
d/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
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 t
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?
>
> O
arn 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
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 ;-)
Ch
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
gt; 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
+ 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:
>
>
> Inte
y1);
result1 <- db.transaction(["foo"]).objectStore("foo").getM(mykey2);
result2 <- db.transaction(["foo"]).objectStore("foo").getM(mykey2);
unit(result1 + result2);
}
Which would be a very neat way of chaining callbacks...
Cheers,
Keean
Whats wrong with callbacks? To me this seems an unnecessary complication.
Presumably you would do:
var promise = db.transaction(["foo"]).objectStore("foo").get(mykey);
var result = promise.get();
if (!result) {
promise.onsuccess(function(res) {...X...});
} else {
...Y...
}
So you end up
Surely the idea is to do more on the client? I for one am using XML web
service APIs on the servers. The client JavaScript/HTTP is downloaded once
into the AppCache. We have 3 or 4 different Web-Service servers performing
different functions (say a registration service, an upload service,
geo-locat
On 8 January 2011 11:45, Glenn Maynard wrote:
> On Sat, Jan 8, 2011 at 6:10 AM, Keean Schupke wrote:
> > I am suggesting that as the semantics are the same, People can think of
> this
> > like serialised access, but implementers can use STMs to make their
> browse
On 8 January 2011 10:00, Glenn Maynard wrote:
> On Sat, Jan 8, 2011 at 4:06 AM, Keean Schupke wrote:
> > If access had to be from inside an "atomic" block (a callback from a
> single
> > storage-thread) then this would fix access from multiple tabs/windows as
>
Hi, Sorry for this small aside, but it (slightly) relevent.
What do you suggest people use instead of e4x in general. For example:
var x = something;
Is a lot more elegant than:
var x2 = document.createTextNode('something');
var x1 = document.createElement('td');
x1.appendChild(x2);
var x0 = do
On 8 January 2011 00:57, Glenn Maynard wrote:
> >> On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchard
> wrote:
> >>> I don't think localStorage should be (to web workers), but
> sessionStorage
> >>> seems
> >>> a reasonable request.
>
> > It's not arbitrary: the names "local" and "session" convey
>
>
>
> Race conditions still happen if you (jarringly) forgot to wrap your
> "shared" object inside atomic block :P. So, maybe it's a good idea to
> only allow localStorage to be accessed inside an atomic block (even in
> workers)?
>
>
>
Yes, that was in my original suggestion.
atomic(function(sh
>
>
> So long as you only allow asynchronous access the implementation can
> ensure that a worker and the main thread doesn't have access to the
> storage at the same time. Then it is safe to allow everyone to modify
> the storage area.
>
> / Jonas
>
>
This is true, serialising access would have th
>
>
> Ok. But what i'm trying to say is, forcing the localStorage to use
> "atomic" block is a bad idea in the main page thread since a
> transaction in the main page thread can span very long time perhaps
> committed by a click event.
How is this any different from having a big loop an any callb
I suggest people read about Software Transactional Memory before trying to
re-invent the wheel. Minds immeasurably superior to our own (spoken in the
voice of Richard Burton) have already thought long and hard about this.
- It solves the efficiency problem
- It solves the long transaction problem
} else {
return true; // retry
}
});
Thats pretty much the entire user visible API that would be needed. Of
course the implementation behind the scenes is more complex.
Cheers,
Keean.
2011/1/6 Keean Schupke
> Here's a link to some papers on STM:
>
> http://researc
ink to the docs:
http://hackage.haskell.org/package/stm
Cheers,
Keean.
2011/1/6 Keean Schupke
> Did you see section 7 in the link I posted?
>
> 7 Implementations
> 7.1 C/C++
> 7.2 C#
> 7.3 Common Lisp
> 7.4 Haskell
> 7.5 Java
> 7.6 OCaml
> 7.7 Perl
> 7.8 Pytho
and other functional
languages (Lisp)... Although as you can see there are plenty of OO
implementations too.
Cheers,
Keean.
2011/1/6 Jonas Sicking
> 2011/1/6 Keean Schupke :
> > There is always Software Transactional Memory that provides a safe model
> for
> > memory shar
There is always Software Transactional Memory that provides a safe model for
memory shared between threads.
http://en.wikipedia.org/wiki/Software_transactional_memory
This has been used very successfully in Haskell for overcoming threading /
state issues. Combined with Haskells Channels (message
On 30 December 2010 23:08, Jonas Sicking wrote:
> On Thu, Dec 30, 2010 at 2:19 PM, Keean Schupke wrote:
> > The JavaScript engine we have implemented has interpreter continuations.
> So
> > at bytecode boundaries it is able to process pending events. (not saying
> it
&g
The JavaScript engine we have implemented has interpreter continuations. So
at bytecode boundaries it is able to process pending events. (not saying it
currently does this, but it may in the future). This is not multi-threading,
there is only one thread per "engine" which maintains an interpreter
e
This is very similar
window.indexedDB.open(..., {
onsuccess: function(event) { ... };
});
Except it requires an extra level on indenting for the callback definitions.
In both this and the current implementation there is the additional overhead
of an object creation for every call, when comp
On 18 December 2010 17:38, Charles Pritchard wrote:
> On 12/17/2010 5:03 PM, Gregg Tavares (wrk) wrote:
>
>
>
> On Fri, Dec 17, 2010 at 4:16 PM, Charles Pritchard wrote:
>
>> We're actively developing such functionality.
>>
>> The limit per directory is for the sake of the os file system. If you
I think I prefer A. Declaring the keys in advance is stating to sound a
little like a schema, and when you go down that route you end up at SQL
schemas (which is a good thing in my opinion). I understand however that
some people are not so comfortable with the idea of a schema, and these
people see
1 - 100 of 155 matches
Mail list logo
