[Bug 9989] New: Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9989 Summary: Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required. Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#han dling-errors-in-utf-8-from-the-server OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#handling-errors-in-utf-8-from-the-server Comment: Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required. Posted from: 88.131.66.80 -- 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: Updates to File API
On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman adria...@microsoft.comwrote: On Tuesday, June 22, 2010 8:40 PM, David Levin wrote: I agree with you Adrian that it makes sense to let the user agent figure out the optimal way of implementing origin and other checks. A logical step from that premise is that the choice/format of the namespace specific string should be left up to the UA as embedding information in there may be the optimal way for some UA's of implementing said checks, and it sounds like other UAs may not want to do that. Robin outlined why that would be a problem [1]. My original feeling was that this should be left up to UAs, as you say, but I've been convinced that doing so is a race to the most complex URL scheme. Robin discussed something that could possibly in http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html. At the same time, there are implementors who gave specific reasons why encoding certain information (scheme, host, port) in the namespace specific string (NSS) is useful to various UAs. No other information has been requested, so theories adding more information seem premature. If the format must be specified, it seems reasonable to take both the theoretical and practical issues into account. Encoding that the security origin in the NSS isn't complex. If a proposal is needed about how that can be done in a simple way, I'm willing to supply one. Also, UAs that don't care about that information are free to ignore it and don't need to parse it. dave
Re: Updates to File API
I think encoding the security origin in the URL allows the UAs to do the security origin check in place, without routing through other authority to get the origin information that might cause the check taking long time to finish. If we worry about showing the double schemes in the URL, we can transform the origin encoded in the URL by using base64 or other escaping algorithm. Jian On Wed, Jun 23, 2010 at 8:24 AM, David Levin le...@google.com wrote: On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman adria...@microsoft.comwrote: On Tuesday, June 22, 2010 8:40 PM, David Levin wrote: I agree with you Adrian that it makes sense to let the user agent figure out the optimal way of implementing origin and other checks. A logical step from that premise is that the choice/format of the namespace specific string should be left up to the UA as embedding information in there may be the optimal way for some UA's of implementing said checks, and it sounds like other UAs may not want to do that. Robin outlined why that would be a problem [1]. My original feeling was that this should be left up to UAs, as you say, but I've been convinced that doing so is a race to the most complex URL scheme. Robin discussed something that could possibly in http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html. At the same time, there are implementors who gave specific reasons why encoding certain information (scheme, host, port) in the namespace specific string (NSS) is useful to various UAs. No other information has been requested, so theories adding more information seem premature. If the format must be specified, it seems reasonable to take both the theoretical and practical issues into account. Encoding that the security origin in the NSS isn't complex. If a proposal is needed about how that can be done in a simple way, I'm willing to supply one. Also, UAs that don't care about that information are free to ignore it and don't need to parse it. dave
[Bug 10000] New: Allow expressions in addition to keyPaths when creating indexes
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1 Summary: Allow expressions in addition to keyPaths when creating indexes Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org For details, see http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1094.html The idea is to allow a full javascript expression to be passed to createIndex. This expression would be run every time a new or modified object is stored in an objectStore. The expression would produce zero or more index values that should be associated with the stored object. There's lots of details to figure out still, such as the syntax of the expression and which context it will be running in. And how non-js implementations would supply this expression. -- 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: [IndexedDB] Computed indexes
On Sat, Jun 19, 2010 at 1:05 AM, Jonas Sicking jo...@sicking.cc wrote:
Maybe we could make
the global scope be empty when compiling (so variables can't be bound) and
executing the function?
Yes, we absolutely should. Forgot to mention this.
What is the difference between an expressionIndex and a keyPath? It seems
like they're doing about the same thing. My proposal to allow keyPath to be
artibrary JavaScript and then have the value being inserted be the global
scope actually sounds almost identical to what you're doingexcept more
in the relm of what JS engines already do (since it's much like an eval).
It is about the same thing yes. Though presumably an implementation
could optimize evaluating the keyPath heavily. Much more so than a
generic expression.
Allowing keyPath to be an arbitrary expression turns out to result in
weird edge cases once you define all details. Say that you're storing
the value:
{ foo: 5, bar: 10 }
You want to evaluate the expression in a context where foo and bar
are in scope. But you also don't want to evaluate with the value as
the global object as then a = 5 would modify the value as that sets
a global variable. I.e. something like t = foo*foo; bar + t; would
add a 't' property to value. And you also don't want to evaluate the
expression in a context where the value is the current scope as then
var a = 5 would modify the value.
Additionally, you have to define what value is returned. We could do
like 'eval' is doing and say that the last evaluated expression is
what is returned. However eval doesn't let you return early using the
'return' statement which might be practical.
These problems could possibly be overcome though. I'll have to check
with people that know JS better than me. Ideas welcome.
I talked to some javascript Gurus here and came up with this proposal:
The string passed in is passed to the javascript Function constructor
in the following manner:
f = new Function(value, passedInExpressionString);
Object.freeze(f);
The resulting function is then executed for each value in the object
store, and the returned value is used as key in the index. If the
returned value is undefined, or if an exception is thrown, no entry is
added to the index. The function is executed in a global scope which
also is frozenand has no available properties other than the ones
defined by the ECMAScript standard. I.e. things like document,
XMLHttpRequest and setTimeout is not available.
Here are some example expressions:
Index on the result of adding two properties together:
return value.a + value.b;
Index on the number of days between two dates:
return (value.to - value.from) / 1000*60*60*24;
Index on a persons last name:
var names = value.name.split(/\\s*/); return names[names.length - 1];
The reason to freeze the global object and the function is to prevent
the expression from retaining state from one execution to the next. We
could also say that a fresh function object and a fresh global scope
object is created, however that would result in slower execution.
/ Jonas
[IndexedDB] Atomic schema changes
Hi All,
In bug 9975 comment 1 [1] Nikunj pointed out that it is unclear how to
make atomic changes to the schema of a database. For example adding an
objectStore and a couple of indexes.
While it actually currently is possible, it is quite quirky and so I
think we need to find a better solution.
One way this is already possible is by calling setVersion. When the
success event fires for this request, it contains an implicitly
created transaction which, while it is alive, holds a lock on the
whole database an prevents any other interactions with the database.
However setVersion is a fairly heavy operation. We have discussed a
couple of different ways it can work, but it seems like there is
agreement that any other open database connections will either have to
be close manually (by for example the user leaving the page), or they
will be close forcefully (by making any requests on them fail). I
intend on sending a starting a separate thread on defining the details
of setVersion.
We might want to allow making smaller schema changes, such as adding a
new objectStore or a new index, without requiring all other database
connections to be closed. Further, it would be nice if atomicness
was a default behavior as to avoid people accidentally creating race
conditions.
We've talked a bit about this at mozilla and have three alternative
proposals. In all three proposals we suggest moving the
createObjectStore to the Transaction interface (or possibly a new
SchemaTransaction interface). The createIndex function remains on
objectStore, but is defined to throw an exception if called outside a
transaction which allows schema changes.
Proposal A:
Always require calls to setVersion for changes to the database schema.
The success event fired on the setVersion request is a
IDBTransactionEvent. The author can use the createObjectStore method
on the transaction available on the event to create new object stores.
Additionally, since we know that no one else currently has an open
database connection, we can make creating objectStores synchronous.
The implementation can probably still asynchronously fail to create an
objectStore, due to diskspace or other hardware issues. This failure
will likely only be detected asynchronously, but can be raised as a
failure to commit the transaction as it is extremely rare.
The code would look something like:
if (db.version == 2.0) {
weAreDoneFunction();
}
db.setVersion(2.0).onsuccess = function(event) {
trans = event.transaction;
store1 = trans.createObjectStore(myStore1, ...);
store2 = trans.createObjectStore(myStore2, ...);
store1.createIndex(...);
store1.createIndex(...);
store2.createIndex(...);
trans.oncomplete = weAreDoneFunction;
}
Proposal B:
Add a new type of transaction SCHEMA_CHANGE, in addition to READ and
READ_WRITE. This transaction is required for any schema changes. As
long as the transaction is open, no other schema changes can be done.
The transaction is opened asynchronously using a new
'startSchemaTransaction' function. This ensures that no other
modifications are attempted at the same time.
Additionally, since we know that no one else currently is inside a
SCHEMA_CHANGE transaction we can make creating objectStores
synchronous. The implementation can probably still asynchronously fail
to create an objectStore, due to diskspace or other hardware issues.
This failure will likely only be detected asynchronously, but can be
raised as a failure to commit the transaction as it is extremely rare.
Code example:
if (db.objectStoreNames.contains(myStore1)) {
weAreDoneFunction();
return;
}
db.startSchemaTransaction().onsuccess = function(event) {
// Have to check again as the objectStore could have been created
before the callback fired
if (db.objectStoreNames.contains(myStore1)) {
weAreDoneFunction();
return;
}
trans = event.transaction;
store1 = trans.createObjectStore(myStore1, ...);
store2 = trans.createObjectStore(myStore2, ...);
store1.createIndex(...);
store1.createIndex(...);
store2.createIndex(...);
trans.oncomplete = weAreDoneFunction;
}
Proposal C:
This is like proposal B, however the schema change transaction is
started synchronously, same as other transactions (we could even reuse
the existing transaction() function, however we'd have to ignore the
storeNames argument).
Since two different pages, running in different processes, could now
start a schema-change transaction at the same time, and thus could
call createObjectStore at the same time and attempt to create the same
store, we have to keep createObjectStore asynchronous.
Code example:
if (db.objectStoreNames.contains(myStore1)) {
weAreDoneFunction();
return;
}
trans = db.startSchemaTransaction();
trans.createObjectStore(myStore1, ...);
trans.createObjectStore(myStore2, ...).onsuccess = function(event) {
store1 = trans.objectStore(myStore1);
store2 = trans.objectStore(myStore2);
store2 = trans.createObjectStore(myStore2, ...);
