Re: [IndexedDB] Atomic schema changes
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 wrote:
> On Fri, Jun 25, 2010 at 9:04 AM, Jonas Sicking wrote:
>>
>> On Thu, Jun 24, 2010 at 4:32 AM, Jeremy Orlow wrote:
>> > On Thu, Jun 24, 2010 at 1:48 AM, Jonas Sicking 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 curren
[IndexedDB] IDBEvent and Event
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: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 9:07 AM, Jeremy Orlow 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
Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
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
> 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: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 5:07 PM, Jeremy Orlow wrote: > On Fri, Jun 25, 2010 at 5:01 PM, John Gregg wrote: > >> >> >> On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow wrote: >> >>> On Fri, Jun 25, 2010 at 4:44 PM, John Gregg 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 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
On Fri, Jun 25, 2010 at 5:01 PM, John Gregg wrote: > > > On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow wrote: > >> On Fri, Jun 25, 2010 at 4:44 PM, John Gregg 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 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
On Fri, Jun 25, 2010 at 8:50 AM, Doug Turner wrote: > > On Jun 25, 2010, at 8:39 AM, John Gregg wrote: > > > > > > > On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner > 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 ">foo" as the body parameter to > createNotification(), the resulting notification must display the string > ">foo", 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 (< 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
On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow wrote: > On Fri, Jun 25, 2010 at 4:44 PM, John Gregg 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 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
On Fri, Jun 25, 2010 at 4:44 PM, John Gregg 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 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
On Jun 25, 2010, at 8:39 AM, John Gregg wrote: > > > On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner 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 ">foo" as the body parameter to > > createNotification(), the resulting notification must display the string > > ">foo", 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 (< 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
> > >> 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 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
On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner 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 ">foo" as the body parameter to > createNotification(), the resulting notification must display the string > ">foo", 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 (< 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
>> >> 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
On Thu, Jun 24, 2010 at 8:00 PM, Doug Turner 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 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
On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner 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
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
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/
Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects
On 6/25/2010 5:09 PM, Anne van Kesteren wrote: On Wed, 23 Jun 2010 01:53:51 +0200, Travis Leithead 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: [IndexedDB] Atomic schema changes
On Fri, Jun 25, 2010 at 9:04 AM, Jonas Sicking wrote:
> On Thu, Jun 24, 2010 at 4:32 AM, Jeremy Orlow wrote:
> > On Thu, Jun 24, 2010 at 1:48 AM, Jonas Sicking 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 ignor
Re: Bubbling/Capturing for XHR + other non-DOM objects
On Wed, 23 Jun 2010 01:53:51 +0200, Travis Leithead 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
On Thu, Jun 24, 2010 at 4:32 AM, Jeremy Orlow wrote:
> On Thu, Jun 24, 2010 at 1:48 AM, Jonas Sicking 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 k
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner 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 ">foo" as the body parameter to >> createNotification(), the resulting notification must display the string >> ">foo", 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
