Re: Thoughts on WebNotification

2010-06-25 Thread Jonas Sicking
On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote:
 Hey Drew,

 I think this is too vague, as it's sounds like a user agent could *not* 
 ignore markup in the string, and still be compliant with the spec. I think 
 we need to be very explicit that the string *must* be treated as plain text. 
 So if I pass in gt;bfoo/b as the body parameter to 
 createNotification(), the resulting notification must display the string 
 gt;bfoo/b, without stripping or converting any of the substrings that 
 might look like HTML entities.

 Yup.  we should tighten up the language.  i think we are on the same page 
 here.

I definitely like the direction this is heading. If we tighten the
language up I would be all for supporting this in firefox. It still
needs to pass through our usual security review and all that, but I
suspect we can make something work.

/ Jonas



Re: [IndexedDB] Atomic schema changes

2010-06-25 Thread Jonas Sicking
On Thu, Jun 24, 2010 at 4:32 AM, Jeremy Orlow jor...@chromium.org wrote:
 On Thu, Jun 24, 2010 at 1:48 AM, Jonas Sicking jo...@sicking.cc wrote:

 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();
 

Re: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-25 Thread Anne van Kesteren
On Wed, 23 Jun 2010 01:53:51 +0200, Travis Leithead tra...@microsoft.com  
wrote:
This topic came up internally on the IE team, and we thought it would be  
noteworthy to put this question before the working groups in hopes of  
getting a spec clarification made.


The question is: for XHR and other non-DOM related objects that support  
the EventTarget interface, meaning objects that will be surfaced off of  
window but aren't really a part of the markup tree, how should event  
propagation be handled?


Events only propagate within a DOM tree. In addition there are some  
special cases for the global object noted in the HTML5 specification.  
Other than that there is no propagation.



--
Anne van Kesteren
http://annevankesteren.nl/



Re: [IndexedDB] Atomic schema changes

2010-06-25 Thread Jeremy Orlow
On Fri, Jun 25, 2010 at 9:04 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Jun 24, 2010 at 4:32 AM, Jeremy Orlow jor...@chromium.org wrote:
  On Thu, Jun 24, 2010 at 1:48 AM, Jonas Sicking jo...@sicking.cc wrote:
 
  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 

Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-25 Thread Brett Zamir

On 6/25/2010 5:09 PM, Anne van Kesteren wrote:
On Wed, 23 Jun 2010 01:53:51 +0200, Travis Leithead 
tra...@microsoft.com wrote:
This topic came up internally on the IE team, and we thought it would 
be noteworthy to put this question before the working groups in hopes 
of getting a spec clarification made.


The question is: for XHR and other non-DOM related objects that 
support the EventTarget interface, meaning objects that will be 
surfaced off of window but aren't really a part of the markup tree, 
how should event propagation be handled?


Events only propagate within a DOM tree. In addition there are some 
special cases for the global object noted in the HTML5 specification. 
Other than that there is no propagation.


This is I guess a bit unrelated, but I was wondering whether thought 
been given to allowing custom events to allow formal propagation beyond 
the document (as described in 
https://developer.mozilla.org/en/Code_snippets/Interaction_between_privileged_and_non-privileged_pages#Sending_data_from_chrome_to_unprivileged_document 
) in a way that works cross-browser?


Although this is more suitable for small-scale experimentation rather 
than formal APIs (especially with events not allowing formal 
namespaces), it would be nice to have a method for allowing 
web-extension communication that could potentially be expanded to work 
in more than one browser, especially as other browsers enhance their 
add-on infrastructure.  (I guess in Firefox the document is all part of 
one big tree that includes the add-on markup, so propagation is indeed 
within the same DOM tree, but not sure whether other browsers treat 
add-ons as fully separate, or if there is at least interest to make them 
work the same way.)


Brett




Re: Thoughts on WebNotification

2010-06-25 Thread Robin Berjon
On Jun 24, 2010, at 21:00 , Doug Turner wrote:
 On Jun 24, 2010, at 11:48 AM, John Gregg wrote:
 interface Permissions {
 
 // permission values
 const unsigned long PERMISSION_ALLOWED = 0;
 const unsigned long PERMISSION_UNKNOWN = 1;
 const unsigned long PERMISSION_DENIED  = 2;

Small nit, but can we have string constants instead (allowed, denied, 
unknown)? They usually turn out to either be less typing or more readable 
depending on whether one uses Permissions.PERMISSION_ALLOWED or 1.

 so, checkPermission and requestPermission.  I am happy with that..

+1

 navigator.permissions.requestPermission(geolocation,desktop-notification,...).

I'd make it an array [geolocation, notifications] but yeah.

 The bigger question is, are other features interested?  Would the 
 Geolocation spec consider using something like this for permissions?
 
 cc'ing Andrei Popescu - the editor of the Geolocation spec.  Not sure how to 
 formally answer your question.  However, if the permission api above was 
 implemented, I think it naturally follows that geolocation would be one of 
 the known strings.

DAP would be interested. To talk process a little bit: if we want to make this 
into a spec it needs a home. In case WebApps can't or won't take it (given how 
complicated rechartering it already is), DAP seem like a natural home for it. 
I'd have to ask the group of course but I'm in favour.

-- 
Robin Berjon - http://berjon.com/






Re: Thoughts on WebNotification

2010-06-25 Thread Robin Berjon
On Jun 24, 2010, at 20:38 , Doug Turner wrote:
 3) Move Web notifications to a version 2 of the specification.  For the most 
 basic use cases, this API isn't required and a web developer could use the 
 more base API to simulate this.  Furthermore, as I mentioned above, many 
 system-level notification services know nothing about rendering html.

I agree that it's better to move optional features to a v2 (or additional 
module). It's not a huge deal but it does help make test suites simpler and 
keeps complexity out of the core document.

-- 
Robin Berjon - http://berjon.com/






Re: Thoughts on WebNotification

2010-06-25 Thread Jeremy Orlow
On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner doug.tur...@gmail.com wrote:

 I have been thinking a bit on Desktop Notifications [1].  After reviewing
 the Web Notification specification [2], I would like to propose the
 following changes:


 1) Factor out the permission api into a new interface and/or spec.  The
 ability to test for a permission without bring up a UI would improve the UX
 of device access.  I could imagine implementing this feature for use with
 Geolocation as well as notifications.  For example:

 interface Permissions {

 // permission values
 const unsigned long PERMISSION_ALLOWED = 0;
 const unsigned long PERMISSION_UNKNOWN = 1;
 const unsigned long PERMISSION_DENIED  = 2;

 void checkPermission(in DOMString type, in Function callback);

 }

 Then we could do something like:

 navigator.permissions.checkPermission(desktop-notification,
 function(value) {});

 or

 navigator.permissions.checkPermission(geolocation, function(value) {});



 2) Add language to the spec to indicate that the DOMStrings used
 |createNotification| are not to include any mark up.  Basically,
 implementations are going to hand off notifications to system-level
 services.  For example, on the Mac, GROWL does not handle any mark up...
 their API just takes plain strings.  I'd like to see the API reflect this
 reality.  Something like the |title| and |body| arguments are to be treated
 as plain text... or some such language.



 3) Move Web notifications to a version 2 of the specification.  For the
 most basic use cases, this API isn't required and a web developer could use
 the more base API to simulate this.  Furthermore, as I mentioned above, many
 system-level notification services know nothing about rendering html.


I'm happy with this course of action, but first I wanted to ask why not the
gracefully degrade suggestion from the Notifications thread started on
the 3rd of Feb.  As far as I can tell, it was never seriously considered,
but several of us brought it up.  And I feel like it'd be a much better way
forward than having a different interface for html based notifications and
text notifications.

(The basic idea was to accept either text or html and then if it's the
latter and the notification scheme doesn't support it, we'd use some simple,
specced heuristics to extract data to be used.  In the thread, there were
some specific ideas about how the transformations could work.  But from a
quick skim, I couldn't find any reasons why it was a bad idea.)

J


Re: Thoughts on WebNotification

2010-06-25 Thread Andrei Popescu
On Thu, Jun 24, 2010 at 8:00 PM, Doug Turner doug.tur...@gmail.com wrote:
 Thank you for your quick response!

 On Jun 24, 2010, at 11:48 AM, John Gregg wrote:

 On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner doug.tur...@gmail.com wrote:
 I have been thinking a bit on Desktop Notifications [1].  After reviewing 
 the Web Notification specification [2], I would like to propose the 
 following changes:


 1) Factor out the permission api into a new interface and/or spec.  The 
 ability to test for a permission without bring up a UI would improve the UX 
 of device access.  I could imagine implementing this feature for use with 
 Geolocation as well as notifications.  For example:

 interface Permissions {

 // permission values
 const unsigned long PERMISSION_ALLOWED = 0;
 const unsigned long PERMISSION_UNKNOWN = 1;
 const unsigned long PERMISSION_DENIED  = 2;

 void checkPermission(in DOMString type, in Function callback);

 }

 Then we could do something like:

 navigator.permissions.checkPermission(desktop-notification, 
 function(value) {});

 or

 navigator.permissions.checkPermission(geolocation, function(value) {});


 I like this idea, I think it's definitely preferable to a one-off permission 
 system just for notifications.

 Your proposal doesn't have a way to explicitly request permission.  Would 
 you be willing to add that, with the recommendation that it only take place 
 on a user gesture?  I don't think this eliminates the ability to implement 
 request-on-first-use, if that's what Mozilla prefers, but I also still think 
 there is benefit to allowing permissions to be obtained separately from 
 invoking the API in question.

 so, checkPermission and requestPermission.  I am happy with that..

 and

 if really want to get crazy, we could do something like:

 navigator.permissions.requestPermission(geolocation,desktop-notification,...).

 This would allow a site to request multiple permissions in one go up to 
 the implementation if this is supported (i'd argue), and up to the 
 implementation on how best to handle these requests.


 The bigger question is, are other features interested?  Would the 
 Geolocation spec consider using something like this for permissions?

 cc'ing Andrei Popescu - the editor of the Geolocation spec.  Not sure how to 
 formally answer your question.  However, if the permission api above was 
 implemented, I think it naturally follows that geolocation would be one of 
 the known strings.


I think it's reasonable. On the other hand, do you think the Geo spec
needs changing to allow this? As I read it, I think it already allows
it.

Thanks,
Andrei



Re: Thoughts on WebNotification

2010-06-25 Thread Doug Turner
 
 cc'ing Andrei Popescu - the editor of the Geolocation spec.  Not sure how to 
 formally answer your question.  However, if the permission api above was 
 implemented, I think it naturally follows that geolocation would be one of 
 the known strings.
 
 
 I think it's reasonable. On the other hand, do you think the Geo spec
 needs changing to allow this? As I read it, I think it already allows
 it.

Clearly no.  Just wanted to give you a heads up.





Re: Thoughts on WebNotification

2010-06-25 Thread John Gregg
On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote:

 Hey Drew,

  I think this is too vague, as it's sounds like a user agent could *not*
 ignore markup in the string, and still be compliant with the spec. I think
 we need to be very explicit that the string *must* be treated as plain text.
 So if I pass in gt;bfoo/b as the body parameter to
 createNotification(), the resulting notification must display the string
 gt;bfoo/b, without stripping or converting any of the substrings that
 might look like HTML entities.
 

 Yup.  we should tighten up the language.  i think we are on the same page
 here.


It's actually more complicated given the various platform behavior.  While
Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in
its notifications (lt; shows , for example) [1, section 5].  So it's not
sufficient to just pass the string directly, it has to be escaped in order
to present the exact text provided.

So perhaps, the user agent must display the string as plain text, without
interpreting markup; if using a notification platform which does interpret
markup, the user agent should modify the string so that any markup is shown
rather than interpreted.

[1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines


Re: Thoughts on WebNotification

2010-06-25 Thread John Gregg


 I'm happy with this course of action, but first I wanted to ask why not
 the gracefully degrade suggestion from the Notifications thread started
 on the 3rd of Feb.  As far as I can tell, it was never seriously considered,
 but several of us brought it up.  And I feel like it'd be a much better way
 forward than having a different interface for html based notifications and
 text notifications.

 (The basic idea was to accept either text or html and then if it's the
 latter and the notification scheme doesn't support it, we'd use some simple,
 specced heuristics to extract data to be used.  In the thread, there were
 some specific ideas about how the transformations could work.  But from a
 quick skim, I couldn't find any reasons why it was a bad idea.)

 J


There were actually several ways considered to combine the interfaces:

- We can a have a method createNotification(text, body, icon, URL) which
uses the URL parameter if supported and text/body/icon parameters to be used
as the backup if HTML content is not supported (I call this the alt text
option).
- We can allow the API to take a URL, load that resource and read some meta
information from it, such as the title tag.  (the title tag option).

I prefer the alt text option between these two, because it is much simpler
to implement for browsers that don't want to support HTML notifications and
would also be better performing, since it doesn't require the resource load.

 -John


Re: Thoughts on WebNotification

2010-06-25 Thread Doug Turner

On Jun 25, 2010, at 8:39 AM, John Gregg wrote:

 
 
 On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote:
 Hey Drew,
 
  I think this is too vague, as it's sounds like a user agent could *not* 
  ignore markup in the string, and still be compliant with the spec. I think 
  we need to be very explicit that the string *must* be treated as plain 
  text. So if I pass in gt;bfoo/b as the body parameter to 
  createNotification(), the resulting notification must display the string 
  gt;bfoo/b, without stripping or converting any of the substrings 
  that might look like HTML entities.
 
 
 Yup.  we should tighten up the language.  i think we are on the same page 
 here.
 
 It's actually more complicated given the various platform behavior.  While 
 Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in 
 its notifications (lt; shows , for example) [1, section 5].  So it's not 
 sufficient to just pass the string directly, it has to be escaped in order to 
 present the exact text provided.
 
 So perhaps, the user agent must display the string as plain text, without 
 interpreting markup; if using a notification platform which does interpret 
 markup, the user agent should modify the string so that any markup is shown 
 rather than interpreted.
 
 [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines


From an implementation pov, this text sorta scares me.  Figuring out which 
notification platform interpret which character sequences sounds hard.  And 
these system are not static and must be reevaluated constantly.

I think it might make it a bunch easier to simply say that UA should strip out 
any escape sequences or html tags.

What do you think?

Doug


Re: Thoughts on WebNotification

2010-06-25 Thread Jeremy Orlow
On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote:


 I'm happy with this course of action, but first I wanted to ask why not
 the gracefully degrade suggestion from the Notifications thread started
 on the 3rd of Feb.  As far as I can tell, it was never seriously considered,
 but several of us brought it up.  And I feel like it'd be a much better way
 forward than having a different interface for html based notifications and
 text notifications.

 (The basic idea was to accept either text or html and then if it's the
 latter and the notification scheme doesn't support it, we'd use some simple,
 specced heuristics to extract data to be used.  In the thread, there were
 some specific ideas about how the transformations could work.  But from a
 quick skim, I couldn't find any reasons why it was a bad idea.)

 J


 There were actually several ways considered to combine the interfaces:

 - We can a have a method createNotification(text, body, icon, URL) which
 uses the URL parameter if supported and text/body/icon parameters to be used
 as the backup if HTML content is not supported (I call this the alt text
 option).
 - We can allow the API to take a URL, load that resource and read some meta
 information from it, such as the title tag.  (the title tag option).


A third option would be to take raw HTML rather than a URL and compute the
text version if necessary.


 I prefer the alt text option between these two, because it is much
 simpler to implement for browsers that don't want to support HTML
 notifications and would also be better performing, since it doesn't require
 the resource load.


The difficulty in implementation is much less important than difficulty in
use is much less important than the difficulty in use.  Although it seems
that at least one mainstream browser will only implement the text conversion
option and thus the alt text version probably won't be as neglected as alt
text in an image (at least initially) and this is something we expect mostly
advanced web developers will use, I still think it's a mistake to assume
web developers will properly support both.  So I would support #2 or my #3
much more than #1 which I would support more than Doug's original suggestion
(for that reason).

J


Re: Thoughts on WebNotification

2010-06-25 Thread John Gregg
On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote:


 I'm happy with this course of action, but first I wanted to ask why not
 the gracefully degrade suggestion from the Notifications thread started
 on the 3rd of Feb.  As far as I can tell, it was never seriously considered,
 but several of us brought it up.  And I feel like it'd be a much better way
 forward than having a different interface for html based notifications and
 text notifications.

 (The basic idea was to accept either text or html and then if it's the
 latter and the notification scheme doesn't support it, we'd use some simple,
 specced heuristics to extract data to be used.  In the thread, there were
 some specific ideas about how the transformations could work.  But from a
 quick skim, I couldn't find any reasons why it was a bad idea.)

 J


 There were actually several ways considered to combine the interfaces:

 - We can a have a method createNotification(text, body, icon, URL) which
 uses the URL parameter if supported and text/body/icon parameters to be used
 as the backup if HTML content is not supported (I call this the alt text
 option).
 - We can allow the API to take a URL, load that resource and read some
 meta information from it, such as the title tag.  (the title tag
 option).


 A third option would be to take raw HTML rather than a URL and compute the
 text version if necessary.


Whenever the spec allows a URL for HTML notifications, I intend that data
url is an option for developers who want to specify the HTML as a string.
 (Chrome supports this already, FYI.)

Or did you mean to suggest that only local HTML would be allowed in the
suggested API, not a remote URL?




 I prefer the alt text option between these two, because it is much
 simpler to implement for browsers that don't want to support HTML
 notifications and would also be better performing, since it doesn't require
 the resource load.


 The difficulty in implementation is much less important than difficulty in
 use is much less important than the difficulty in use.  Although it seems
 that at least one mainstream browser will only implement the text conversion
 option and thus the alt text version probably won't be as neglected as alt
 text in an image (at least initially) and this is something we expect mostly
 advanced web developers will use, I still think it's a mistake to assume
 web developers will properly support both.  So I would support #2 or my #3
 much more than #1 which I would support more than Doug's original suggestion
 (for that reason).


I see the developer-side complexity the opposite way.  In #1 the backup plan
is very explicit, in #2/3 for the developer to get good results on text-only
platforms they have to understand our heuristics.  We haven't specified them
exactly, but I would speculate that using them would involve at least as
much effort as specifying the backup plan explicitly.

 -John


Re: Thoughts on WebNotification

2010-06-25 Thread John Gregg
On Fri, Jun 25, 2010 at 8:50 AM, Doug Turner doug.tur...@gmail.com wrote:


 On Jun 25, 2010, at 8:39 AM, John Gregg wrote:

 
 
  On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com
 wrote:
  Hey Drew,
 
   I think this is too vague, as it's sounds like a user agent could *not*
 ignore markup in the string, and still be compliant with the spec. I think
 we need to be very explicit that the string *must* be treated as plain text.
 So if I pass in gt;bfoo/b as the body parameter to
 createNotification(), the resulting notification must display the string
 gt;bfoo/b, without stripping or converting any of the substrings that
 might look like HTML entities.
  
 
  Yup.  we should tighten up the language.  i think we are on the same page
 here.
 
  It's actually more complicated given the various platform behavior.
  While Growl doesn't interpret markup, NotifyOSD on linux does allow some
 markup in its notifications (lt; shows , for example) [1, section 5].  So
 it's not sufficient to just pass the string directly, it has to be escaped
 in order to present the exact text provided.
 
  So perhaps, the user agent must display the string as plain text,
 without interpreting markup; if using a notification platform which does
 interpret markup, the user agent should modify the string so that any markup
 is shown rather than interpreted.
 
  [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines


 From an implementation pov, this text sorta scares me.  Figuring out which
 notification platform interpret which character sequences sounds hard.  And
 these system are not static and must be reevaluated constantly.

 I think it might make it a bunch easier to simply say that UA should strip
 out any escape sequences or html tags.

 What do you think?


I'm concerned that it would make it impossible to display a certain category
of strings in notifications.  Suppose we're both web devs, I'm chatting with
you and want to share with you a snippet of code; will the chat notification
be blank?

I agree with the problem of depending on the providers, but if we do want to
be able to specify dependable output for input (my interpretation of this
discussion), I think we have to make some sort of effort there.

 -John

 -John


Re: Thoughts on WebNotification

2010-06-25 Thread Jeremy Orlow
On Fri, Jun 25, 2010 at 5:01 PM, John Gregg john...@google.com wrote:



 On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote:


 I'm happy with this course of action, but first I wanted to ask why not
 the gracefully degrade suggestion from the Notifications thread started
 on the 3rd of Feb.  As far as I can tell, it was never seriously 
 considered,
 but several of us brought it up.  And I feel like it'd be a much better way
 forward than having a different interface for html based notifications and
 text notifications.

 (The basic idea was to accept either text or html and then if it's the
 latter and the notification scheme doesn't support it, we'd use some 
 simple,
 specced heuristics to extract data to be used.  In the thread, there were
 some specific ideas about how the transformations could work.  But from a
 quick skim, I couldn't find any reasons why it was a bad idea.)

 J


 There were actually several ways considered to combine the interfaces:

 - We can a have a method createNotification(text, body, icon, URL) which
 uses the URL parameter if supported and text/body/icon parameters to be used
 as the backup if HTML content is not supported (I call this the alt text
 option).
 - We can allow the API to take a URL, load that resource and read some
 meta information from it, such as the title tag.  (the title tag
 option).


 A third option would be to take raw HTML rather than a URL and compute the
 text version if necessary.


 Whenever the spec allows a URL for HTML notifications, I intend that data
 url is an option for developers who want to specify the HTML as a string.
  (Chrome supports this already, FYI.)


Good point.  Never mind on this third option.


 Or did you mean to suggest that only local HTML would be allowed in the
 suggested API, not a remote URL?




 I prefer the alt text option between these two, because it is much
 simpler to implement for browsers that don't want to support HTML
 notifications and would also be better performing, since it doesn't require
 the resource load.


 The difficulty in implementation is much less important than difficulty in
 use is much less important than the difficulty in use.  Although it seems
 that at least one mainstream browser will only implement the text conversion
 option and thus the alt text version probably won't be as neglected as alt
 text in an image (at least initially) and this is something we expect mostly
 advanced web developers will use, I still think it's a mistake to assume
 web developers will properly support both.  So I would support #2 or my #3
 much more than #1 which I would support more than Doug's original suggestion
 (for that reason).


 I see the developer-side complexity the opposite way.  In #1 the backup
 plan is very explicit, in #2/3 for the developer to get good results on
 text-only platforms they have to understand our heuristics.  We haven't
 specified them exactly, but I would speculate that using them would involve
 at least as much effort as specifying the backup plan explicitly.


Well, getting things to look would possibly take more effort on a web
developer's part, but having _anything_ show up (for developers who only
target browsers that support HTML) would always work...even if poorly.  With
Doug's proposal and the alt text proposal, if developers target a browser
that only supports HTML, then things will completely break in browsers that
don't support it.  Maybe that's OK though?

If the conversion algorithm is well specified, getting it to work in one
text only browser would mean it works in all of them.  (If they all follow
the spec that is.)

J


Re: Thoughts on WebNotification

2010-06-25 Thread Jeremy Orlow
On Fri, Jun 25, 2010 at 5:07 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Fri, Jun 25, 2010 at 5:01 PM, John Gregg john...@google.com wrote:



 On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow jor...@chromium.orgwrote:

 On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote:


 I'm happy with this course of action, but first I wanted to ask why
 not the gracefully degrade suggestion from the Notifications thread
 started on the 3rd of Feb.  As far as I can tell, it was never seriously
 considered, but several of us brought it up.  And I feel like it'd be a 
 much
 better way forward than having a different interface for html based
 notifications and text notifications.

 (The basic idea was to accept either text or html and then if it's the
 latter and the notification scheme doesn't support it, we'd use some 
 simple,
 specced heuristics to extract data to be used.  In the thread, there were
 some specific ideas about how the transformations could work.  But from a
 quick skim, I couldn't find any reasons why it was a bad idea.)

 J


 There were actually several ways considered to combine the interfaces:

 - We can a have a method createNotification(text, body, icon, URL) which
 uses the URL parameter if supported and text/body/icon parameters to be 
 used
 as the backup if HTML content is not supported (I call this the alt text
 option).
 - We can allow the API to take a URL, load that resource and read some
 meta information from it, such as the title tag.  (the title tag
 option).


 A third option would be to take raw HTML rather than a URL and compute
 the text version if necessary.


 Whenever the spec allows a URL for HTML notifications, I intend that data
 url is an option for developers who want to specify the HTML as a string.
  (Chrome supports this already, FYI.)


 Good point.  Never mind on this third option.


  Or did you mean to suggest that only local HTML would be allowed in the
 suggested API, not a remote URL?




 I prefer the alt text option between these two, because it is much
 simpler to implement for browsers that don't want to support HTML
 notifications and would also be better performing, since it doesn't require
 the resource load.


 The difficulty in implementation is much less important than difficulty
 in use is much less important than the difficulty in use.  Although it seems
 that at least one mainstream browser will only implement the text conversion
 option and thus the alt text version probably won't be as neglected as alt
 text in an image (at least initially) and this is something we expect mostly
 advanced web developers will use, I still think it's a mistake to assume
 web developers will properly support both.  So I would support #2 or my #3
 much more than #1 which I would support more than Doug's original suggestion
 (for that reason).


 I see the developer-side complexity the opposite way.  In #1 the backup
 plan is very explicit, in #2/3 for the developer to get good results on
 text-only platforms they have to understand our heuristics.  We haven't
 specified them exactly, but I would speculate that using them would involve
 at least as much effort as specifying the backup plan explicitly.


 Well, getting things to look


er...meant to say look good


 would possibly take more effort on a web developer's part, but having
 _anything_ show up (for developers who only target browsers that support
 HTML) would always work...even if poorly.  With Doug's proposal and the alt
 text proposal, if developers target a browser that only supports HTML, then
 things will completely break in browsers that don't support it.  Maybe
 that's OK though?

 If the conversion algorithm is well specified, getting it to work in one
 text only browser would mean it works in all of them.  (If they all follow
 the spec that is.)


I suppose that we could spec it such that if someone creates a HTML
notification (in Doug's proposal) or doesn't specify alt text in the alt
text proposal, we fall back to some algorithm/heuristics to do the
conversion automatically.  It'd be the most complicated implementation wise,
but it'd be the best solution for the web developer.

J


Re: Thoughts on WebNotification

2010-06-25 Thread Doug Turner
 I'm concerned that it would make it impossible to display a certain category 
 of strings in notifications.  Suppose we're both web devs, I'm chatting with 
 you and want to share with you a snippet of code; will the chat notification 
 be blank?
 
 I agree with the problem of depending on the providers, but if we do want to 
 be able to specify dependable output for input (my interpretation of this 
 discussion), I think we have to make some sort of effort there. 

make sense.  i agree with you.


Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

2010-06-25 Thread Boris Zbarsky

On 6/25/10 5:56 AM, Brett Zamir wrote:

I guess in Firefox the document is all part of
one big tree that includes the add-on markup, so propagation is indeed
within the same DOM tree


It's not, actually.  In Firefox, an event will bubble from a Window to 
some object in the browser UI associated with that Window.  This object 
is the same for a page and all its subframes.


What this object is is effectively an implementation detail.

Note that we plan to keep this behavior as we move to a multi-process 
architecture, at which point the event will effectively bubble across 
the process boundary.


-Boris



Re: Thoughts on WebNotification

2010-06-25 Thread Drew Wilson
On Fri, Jun 25, 2010 at 9:07 AM, Jeremy Orlow jor...@chromium.org wrote:



 Well, getting things to look would possibly take more effort on a web
 developer's part, but having _anything_ show up (for developers who only
 target browsers that support HTML) would always work...even if poorly.  With
 Doug's proposal and the alt text proposal, if developers target a browser
 that only supports HTML, then things will completely break in browsers that
 don't support it.  Maybe that's OK though?

 If the conversion algorithm is well specified, getting it to work in one
 text only browser would mean it works in all of them.  (If they all follow
 the spec that is.)

 J


An implicit assumption here is that a single block of HTML can both provide
an attractive HTML-formatted display, and also be converted to plain text in
a way that is attractive for plain text notification mechanisms (I also
don't know how this addresses use cases like SVG notifications).  I think
that developers would inherently have to test both if they want to support
both, so I'm not sure this helps.

As a developer, I like the current API as it allows me to detect rich
notification support via the presence of createWebNotification(), but also
allows the user's preference (growl-only, for example) to be expressed even
on browsers that can support web notifications by not exposing that API. I
may be more blithely confident in developer's abilities to do capability
detection than others in this discussion, though :)

The advantage of the alt-text solution is it gracefully degrades (you won't
get an exception thrown if you screw up capabilities detection) but you also
can't do capability detection. I'm not 100% convinced that capabilities
detection is important (offhand I'm not able to come up with any compelling
use cases where I'd only want to display an HTML notification and not
display any notification at all if they are not supported), so I'd support
ditching the current API in favor of alt-text if that would lead to more
interoperability.

-atw


[IndexedDB] IDBEvent and Event

2010-06-25 Thread Shawn Wilsher

Hey all,

I think that IDBEvent needs to inherit from Event [1] in order for us to 
properly inherit from EventTarget in IDBRequest.  Specifically, 
EventTarget takes an EventListener [2] which has a method, handleEvent, 
that takes an Event object.  I'm not sure this makes sense for us 
though, so I figured I'd start a discussion before filing the bug.


Cheers,

Shawn

[1] http://www.w3.org/TR/DOM-Level-3-Events/#interface-Event
[2] http://www.w3.org/TR/DOM-Level-3-Events/#interface-EventListener



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [IndexedDB] Atomic schema changes

2010-06-25 Thread Mikeal Rogers
In IDBCouch I don't have a schema but I do have to maintain
consistency of the by-sequence index which is a similar problem to
validating schema state before these kinds of operations.

What I'm currently doing is just starting each write transaction with
a lookup to the end of the by-sequence index to make sure the
lastSequence I have is, in fact, the current one and another
tab/window hasn't updated it.

My plan for view generation is a similar problem and I plan to solve
it with a an objectStore of meta information about all of the views.
Storing the last known sequence and conflict resolution information
about replicas is also a similar problem and I'll solve it the same
way with a meta objectStore.

I don't see why schema information couldn't also be stored in a meta
objectStore at the end transactions that modify it and all of these
higher level APIs could just start their transaction with a validation
of the meta info. Rather than trying to keep the information globally
and updating it with an event you can just validate it at the
beginning of each transaction. The overhead is minimal and it seems,
to me at least, to be a little less error prone.

-Mikeal

On Fri, Jun 25, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote:
 On Fri, Jun 25, 2010 at 9:04 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Jun 24, 2010 at 4:32 AM, Jeremy Orlow jor...@chromium.org wrote:
  On Thu, Jun 24, 2010 at 1:48 AM, Jonas Sicking jo...@sicking.cc wrote:
 
  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