[Bug 8406] New: Stricter Specifications on Mouse Events Specifically primary, auxillary, and secondary default actions
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8406 Summary: Stricter Specifications on Mouse Events Specifically primary, auxillary, and secondary default actions Product: WebAppsWG Version: unspecified Platform: All URL: http://dev.w3.org/2006/webapi/DOM-Level-3- Events/html/DOM3-Events.html#events-mouseevents OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DOM3 Events AssignedTo: schep...@w3.org ReportedBy: warcraftthre...@sbcglobal.net QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org This covers a few things related to MouseEvents. In order to get rid of OnContextMenu and to supply a standard way to deal with the middle mouse button mouseup should have its Default action defined in the specification. The button for MouseEvent already has the comment: During mouse events caused by the depression or release of a mouse button, button shall be used to indicate which pointer device button changed state. 0 must indicate the primary button of the device (in general, the left button or the only button on single-button devices, used to activate a user interface control or select text). 2 must indicate the secondary button (in general, the right button, often used to display a context menu). 1 must indicate the auxiliary button (in general, the middle button, often combined with a mouse wheel). Some mice may provide or simulate more buttons, and values higher than 2 may be used to represent such buttons. - http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-MouseEvent-button So we have 0 - Left Mouse Button 1 - Middle Mouse Button 2 - Right Mouse Button Since the event click already handles buttons and links and has a prevent default that means for mousedown and mouseup the left mouse button doesn't require any changes. However, middle mouse button does have a default action whether the specification says so or not. In many browsers it creates a scroll icon allowing the user to scroll by moving the mouse. This behavior should be denoted as the default action when button = 1. For button = 2 (right mouse button) the context menu should be denoted as the default action. Using the preventDefault should allow one to cancel these default actions at the browser level. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-event-type-preventDefault This should clear up any confusion about mouse buttons and should allow for a seamless transition into web applications. With this the left, middle, and right mouse buttons can be utilized. How browsers implement or override this functionality is up to them, but right now this is a mess and it needs to be specified. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [webworkers] SharedWorker and ApplicationCache
On Sat, 7 Nov 2009, Anne van Kesteren wrote: We were wondering why there is a quite complicated resolution algorithm to determine the ApplicationCache that belongs to the SharedWorker rather than just passing the ApplicationCache to the SharedWorker at creation time (i.e. as constructor argument). Is there anything that is gained by the current model? It's not that complicated; it's the same algorithm as you have for just going straight to a URL directly. On Sat, 7 Nov 2009, Drew Wilson wrote: You may have two separate pages running from different app caches (or version), each of which is trying to access the same shared worker, so we don't want to tie it explicitly to a specific parent's app cache/version. It does seem a bit wonky, though - if you have one parent who has an app cache that has two resources in it (a.js and b.js) and another parent who has an app cache that has a different two resources in it (a.js and c.js), it's non-deterministic which app cache the shared worker would be associated with, and this could break apps. I'm not sure that there's a good solution for this, given that manifests can only be associated with an HTML resource. It's the same problem with opening an iframe to a page that is in multiple caches. On Sat, 7 Nov 2009, Michael Nordman wrote: I've been wondering if SharedWorkers should have a means of establishing an appcache similar to how pages can via the html manifest='x' mechanism. My mental model is that a shared worker is very much like a top-level page with respect to appcaches, but that means for a shared worker to express/establish its appcache is missing. You don't need to specify the appcache in the shared worker, because the user is never going to open a worker directly. Thus, the author just has to make sure to mention the worker in the app manifest, and it'll be fine. It can get hairy if you have multiple manifests that mention the same shared worker, and I guess in that situation you might want to have a manifest declared so that there can always be one version of the shared worker, shared by all the apps, but then you can emulate that for now using an iframe that just declares a manifest with just the shared worker (and that iframe can also be used to proxy access to the shared worker for other domains, if necessary), so I don't think we need to add it to the spec straight away -- we can add it later if it really would be useful. On Sat, 7 Nov 2009, Drew Wilson wrote: Yeah, I thought about this some back when I was trying to piece together a proposal for persistent workers. I suppose you could pass an optional manifest URL to the SharedWorker constructor, with appropriate restrictions on different pages creating the same SharedWorker but with different manifest URLs. Since there's already an optional name parameter, you could always require the name to be specified if you are specifying an app cache URL (so the third argument to the constructor would always be the manifest URL). On Sat, 7 Nov 2009, Michael Nordman wrote: I was thinking something more in parallel with how HTML pages establish the appcache association. There are very precise algorithms that define how this cache association is to be performed for 'master-entry' pages. I think ll of those algorithms could apply to shared worker scripts, if only shared worker scripts possessed a means to declare an association with a manifest file. What is missing is a means for the worker script to declare that association. I agree with Michael that this would make more sense as an in-file marker. On Mon, 9 Nov 2009, Alexey Proskuryakov wrote: Don't shared workers depend on HTML documents for network loading? No. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [public-webapps] Comments on Widget URI (General)
Hi Larry, On Nov 19, 2009, at 15:18 , Robin Berjon wrote: the WebApps WG deeply thank you for you comments on the widgets URI last call. We decided to split them over several emails that have been posted to the list with proposed responses to them. We would be grateful if you could indicate whether you are satisfied with each resolution within two weeks. On Thursday it will be two weeks since the WG has sent out its response to your comments concerning widget URIs. In the spirit of not having to fall back to the rule that silence is assent it would be great if you could indicate whether you are satisfied with each proposed resolution. We naturally understand that you may be busy, so if time is short we can also discuss pushing the date somewhat. Regards, -- Robin Berjon - http://berjon.com/
Re: [widgets] element-based localization
On Nov 30, 2009, at 22:33 , Marcos Caceres wrote: I *really* like it; you never fail to impress Mr Berjon :) *bows* I learn from working with the best, sir. ... but the first para should just be a Note: (we don't want to have that in as normative text because it describes behavior specified in the XML spec... hence, I would add as specified in [XML], bla bla bla). The second paragraph can serve as a normative definition to which all localizable via xml:lang link to. Can you live with that? Yes, certainly! If you can, I have added the above to the spec. With that, we are ready to go to CR so please give me your consent. Sorry man, I'm already married. -- Robin Berjon - http://berjon.com/
Re: [widgets] element-based localization
Robin Berjon wrote: On Nov 30, 2009, at 22:33 , Marcos Caceres wrote: I *really* like it; you never fail to impress Mr Berjon :) *bows* I learn from working with the best, sir. ... but the first para should just be a Note: (we don't want to have that in as normative text because it describes behavior specified in the XML spec... hence, I would add as specified in [XML], bla bla bla). The second paragraph can serve as a normative definition to which all localizable via xml:lang link to. Can you live with that? Yes, certainly! Yay. If you can, I have added the above to the spec. With that, we are ready to go to CR so please give me your consent. Sorry man, I'm already married. Dammit! she one lucky lady.
Re: [widgets] element-based localization
Hi Marcos, Robin, Marcos Caceres a écrit : On Mon, Nov 30, 2009 at 3:41 PM, Robin Berjon ro...@berjon.com wrote: On Nov 27, 2009, at 20:55 , Marcos Caceres wrote: On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato cyril.concol...@enst.fr wrote: I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. D'oh! that should be a localizable: yes. Thankfully, that's there for author clarification. Really? I wouldn't have thought so. There's a difference between you can have xml:lang there and it is meaningful to have xml:lang there (or on its ancestors). You can have xml:lang on widget, but the widget element cannot really be localised (you can't have two, choosing between them depending on locale). It's not a huge difference, but putting localisable: yes on widget would confuse me. Agreed. I agree too, the widget element should stay with localizable: no but with a possible xml:lang attribute. I've added this to the editor's draft: As part of their definition, the XML elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, including any element in the widget namespace. During Step 7, the user agent will apply the standardized behavior of xml:lang specified in the [XML] specification (i.e. inheritance and propagation of the xml:lang attribute will occur on child elements on which it was not explicitly used - see example below to see how this inheritance and propagation works). Regardless of whether xml:lang was inherited or explicitly used in an element, a user agent will only use the value of an xml:lang attributes for the purpose of element-based localization in Step 7 when that element was explicitly marked with the text Localizable via xml:lang: Yes as part of that elements definition. WDYT? I think that this is even more confused than the original :) To clarify, I think you need to make the same distinction I made above re can have xml:lang and supports being localised. Otherwise you get sentences like elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, to which I can only reply ebbeh?. How about: The xml:lang attribute can be used on any element in order to indicate which language is used in the content and attribute values of that element. Its value is inherited, such that if an element has an xml:lang attribute, all of its descendants are considered to be in that language as well, unless they specify their own xml:lang attribute. Note that an element can indicate that it is in no specific language by setting xml:lang to the empty string, irrespective of whether any of its ancestors has an xml:lang attribute. Some of the elements in the widgets namespace are defined to be localisable. This means that they will be processed in a specific manner if they have an xml:lang value (directly or through inheritance), as described in detail in Step 7. WDYT? I *really* like it; you never fail to impress Mr Berjon :) ... but the first para should just be a Note: (we don't want to have that in as normative text because it describes behavior specified in the XML spec... hence, I would add as specified in [XML], bla bla bla). The second paragraph can serve as a normative definition to which all localizable via xml:lang link to. Can you live with that? I agree with Robin's text and with your suggestion to have as specified in [XML]. Cyril If you can, I have added the above to the spec. With that, we are ready to go to CR so please give me your consent. -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Fwd: Welcome to the W3C web security mailing list
FYI. The focus of this new mailing list is broader than the focus of the current mailing list. If you're interested in joining, send an e-mail with the subject subscribe to public-web-security-requ...@w3.org. -- Thomas Roessler, W3C t...@w3.org Begin forwarded message: From: Thomas Roessler t...@w3.org Date: 1 December 2009 15:48:27 GMT+01:00 To: public-web-secur...@w3.org Cc: Thomas Roessler t...@w3.org Subject: Welcome to the W3C web security mailing list With some delay after the security BOF at TPAC, welcome to the W3C web security mailing list. If you want to get off this mailing list, please either contact me directly, or send a note with the subject unsubscribe to public-web-security-requ...@w3.org. The list has a publicly visible archive: http://lists.w3.org/Archives/Public/public-web-security/ A companion wiki is also available (writable for anybody with a W3C web account); I've put in a little bit of content to jump-start things (no full minutes from the BOF at TPAC, though): http://www.w3.org/Security/wiki/ The scope of the list is broad: Improving standards and implementations to advance the security of the Web. What's meant by this is that this mailing list is the right place to discuss topics like: - new specs that people want to bring to W3C, IETF or other relevant standards bodies - emerging security issues - bigger themes, like how and where to document the same origin policy With that, it's over to you! -- Thomas Roessler, W3C t...@w3.org
Re: CfC - publish Selectors API as CR
On Thu, 19 Nov 2009 00:49:58 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi folks, this is a Call for consensus to request publishing the Selectors API draft at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1 as a Candidate Recommendation (assuming Lachy fixes the apparent encoding errors, the incorrect URIs and so on as editorial corrections). Given wide support, and no objections, the resolution of the working group is to request publication of the document as a CR. cheers, and thanks chaals The proposed exit criteria are in a separate thread, but essentially are: For a set of tests based on HTML, CSS 2.1 selectors and this spec, there are two implementations that pass every test interoperably, and do not fail any additional tests based on misimplementing this specification (i.e. failures based on not supporting a technology used only in the additional tests, such as MathML, will not be taken into account). Note that the test suite has not been agreed by the Working Group, and will not be required for the transition request. Agreeing on a test suite will be part of the work we have to do before this spec can move futher than CR. Please respond yes or no before the end of Friday 27 November. Silence will be taken as assent, but this call will not be considered to result in a resolution without a reasonable level of positive response. Cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [widgets] element-based localization
On Tuesday, December 1, 2009, Cyril Concolato cyril.concol...@enst.fr wrote: Hi Marcos, Robin, Marcos Caceres a écrit : On Mon, Nov 30, 2009 at 3:41 PM, Robin Berjon ro...@berjon.com wrote: On Nov 27, 2009, at 20:55 , Marcos Caceres wrote: On Thu, Nov 26, 2009 at 2:40 PM, Cyril Concolato cyril.concol...@enst.fr wrote: I'm trying to implement the element-based localization and I found the spec unclear with regards to the inheritance of th xml:lang attribute and I would like to propose some improved text. First, this attribute is listed as an optional attribute of the widget element but the widget element is not localizable, so one does not understand why. D'oh! that should be a localizable: yes. Thankfully, that's there for author clarification. Really? I wouldn't have thought so. There's a difference between you can have xml:lang there and it is meaningful to have xml:lang there (or on its ancestors). You can have xml:lang on widget, but the widget element cannot really be localised (you can't have two, choosing between them depending on locale). It's not a huge difference, but putting localisable: yes on widget would confuse me. Agreed. I agree too, the widget element should stay with localizable: no but with a possible xml:lang attribute. I've added this to the editor's draft: As part of their definition, the XML elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, including any element in the widget namespace. During Step 7, the user agent will apply the standardized behavior of xml:lang specified in the [XML] specification (i.e. inheritance and propagation of the xml:lang attribute will occur on child elements on which it was not explicitly used - see example below to see how this inheritance and propagation works). Regardless of whether xml:lang was inherited or explicitly used in an element, a user agent will only use the value of an xml:lang attributes for the purpose of element-based localization in Step 7 when that element was explicitly marked with the text Localizable via xml:lang: Yes as part of that elements definition. WDYT? I think that this is even more confused than the original :) To clarify, I think you need to make the same distinction I made above re can have xml:lang and supports being localised. Otherwise you get sentences like elements of the configuration document are marked as being localizable via xml:lang with either the word yes or no. An author can use the xml:lang attribute on any XML element, to which I can only reply ebbeh?. How about: The xml:lang attribute can be used on any element in order to indicate which language is used in the content and attribute values of that element. Its value is inherited, such that if an element has an xml:lang attribute, all of its descendants are considered to be in that language as well, unless they specify their own xml:lang attribute. Note that an element can indicate that it is in no specific language by setting xml:lang to the empty string, irrespective of whether any of its ancestors has an xml:lang attribute. Some of the elements in the widgets namespace are defined to be localisable. This means that they will be processed in a specific manner if they have an xml:lang value (directly or through inheritance), as described in detail in Step 7. WDYT? I *really* like it; you never fail to impress Mr Berjon :) ... but the first para should just be a Note: (we don't want to have that in as normative text because it describes behavior specified in the XML spec... hence, I would add as specified in [XML], bla bla bla). The second paragraph can serve as a normative definition to which all localizable via xml:lang link to. Can you live with that? I agree with Robin's text and with your suggestion to have as specified in [XML]. Great, that's what we published Cyril If you can, I have added the above to the spec. With that, we are ready to go to CR so please give me your consent. -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat -- Marcos Caceres http://datadriven.com.au
RE: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December
Hi Art, All, ACCESS does not support this publication. Our motivation is that the comments received during the LC#1 were not all addressed. Since the PAG has started with the earlier draft of WARP and relation to PAG was an argument for LC#2, we assume that the group still has time to accommodate the LC#1 comments in the present version of the specification without the detrimental effect on the proceedings within PAG. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Friday, November 27, 2009 3:50 PM To: public-webapps Subject: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December This is a Call for Consensus (CfC) to publish Last Call Working Draft #2 of: http://dev.w3.org/2006/waf/widgets-access/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note that as specified in the Process Document [PD], a Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is December 2. For some additional background on this proposal, see: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0947.html -Art Barstow Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December
On Tuesday, December 1, 2009, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Art, All, ACCESS does not support this publication. Our motivation is that the comments received during the LC#1 were not all addressed. Please list exactly which comment were not addressed. Since the PAG has started with the earlier draft of WARP and relation to PAG was an argument for LC#2, we assume that the group still has time to accommodate the LC#1 comments in the present version of the specification without the detrimental effect on the proceedings within PAG. that's absurd. The PAG had no bearing on this work. Work continues as normal. Also, what the PAG has or had not done is member confidential; please stop discussing PAG matters in public. If you have *actual* issues with the current draft, list them quickly so we can address them ASAP. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Friday, November 27, 2009 3:50 PM To: public-webapps Subject: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December This is a Call for Consensus (CfC) to publish Last Call Working Draft #2 of: http://dev.w3.org/2006/waf/widgets-access/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note that as specified in the Process Document [PD], a Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is December 2. For some additional background on this proposal, see: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0947.html -Art Barstow Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you. -- Marcos Caceres http://datadriven.com.au
Transaction callback for localStorage mutex?
I haven't been following the localStorage mutex discussion in detail,
but have we already rejected the idea of having content specifically
ask for the mutex via a transaction callback, similar to how web
databases work?
localStorgage.atomicTransaction(function() {
localStorage[counter]++;
});
Adam
Re: Transaction callback for localStorage mutex?
On Tue, Dec 1, 2009 at 6:18 PM, Adam Barth w...@adambarth.com wrote:
I haven't been following the localStorage mutex discussion in detail,
but have we already rejected the idea of having content specifically
ask for the mutex via a transaction callback, similar to how web
databases work?
localStorgage.atomicTransaction(function() {
localStorage[counter]++;
});
Yes, the idea was rejected because if it is required then it is a
breaking change to local storage, and if it isn't required, then
authors won't use it because they'll be lazy.
- a
Re: Transaction callback for localStorage mutex?
On Tue, 1 Dec 2009, Adam Barth wrote: I haven't been following the localStorage mutex discussion in detail, but have we already rejected the idea of having content specifically ask for the mutex via a transaction callback, similar to how web databases work? One of the limitations is we can't change the API (since it already shipped in IE). If we could change the API, it'd be trivial to fix. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Let's turn WebDatabase into a WG Note
On Tue, 17 Nov 2009, Nikunj R. Mehta wrote: While good work has gone into the IDL/JavaScript Call Level Interface (CLI), we have made no progress on its SQL language specification and are not likely to in the future. For the record, we've made no progress because I explicitly wasn't going to do it until 2010. If either Microsoft or Mozilla (or ideally both) are interested in implementing this after all, I would be quite willing to write the spec for SQL to the same level of detail as HTML5. In the absence of interest in the matter, however, I'm happy to let the spec stand without a definition of the SQL dialect beyond just use sqlite. It just means we can't progress the spec past CR. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [webdatabase] Handling of the query arguments
On Thu, 19 Nov 2009, Maciej Stachowiak wrote: ECMAScript defines a ToPrimitive conversion (Section 9.1 of ECMA-262 5th edition). I think the right thing to do would be for some spec to point to those steps. Probably it has to be Web Database, because in many cases where a Web IDL method takes an any type, it's not appropriate to do ToPrimitive conversion. So required. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
WebSimpleDB Issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I had few thoughts/questions/issues with the WebSimpleDB proposal: * No O(log n) access to position/counts in index sequences - If you want find all the entities that have a price less than 10, it is quite easy (assuming there is an index on that property) with the WebSimpleDB to access the price index, iterate through the index until you hit 10 (or vice versa). However, if this is a large set of data, the vast majority of applications I have built involve providing a subset or page of data at a time to keep constant or logarithmic time access to data, *and* an indication of how many rows/items/entities are available. Limiting a query to a certain number of items is easy enough with WebSimple, you just only iterate so far, but determining how many items are less than 10 is no longer a logarithmic complexity problem, but is linear with the number of items that are less 10, because you have to iterate over all of them to count them. If a cursor were to indicate the numeric position within an index (even if it was an estimate, without transactional strictness), one could easily determine the count of these type of queries in O(log n) time. This would presumably entail B-tree nodes keeping track of their number of children. * Asynchronicity is not well-aligned with the expensive operations - The asynchronous actions are starting and committing transactions. It makes sense that committing transactions would be expensive, but why do we make the start of a transaction asynchronous? Is there an expectation that the a global lock will be sought on the entire DB when the transaction is started? That certainly doesn't seem desirable. Normally a DB would create locks as data is accessed, correct? If anything a get operation would be more costly than starting a transaction. * Hanging EntityStores off of transactions creates unnecessary complexity in referencing stores - A typical pattern in applications is to provide a reference to a store to a widget that will use it. However, with the WebSimpleDB, you can't really just hand off a reference to an EntityStore, since each store object is transaction-specific. You would either need to pass the name of store to a widget, and have it generate its own transaction to get a store (which seems like very bad form from object capability perspective), or pass in a store for every action, which may not be viable in many situations. Would it be reasonable (based on the last two points) to have getEntityStore be a method on database objects, rather than transaction objects? Actions would just take place in the current transaction for the context. With the single-threaded nature of JS contexts, having a single active transaction at a time doesn't not seem like a hardship, but rather makes things a lot simpler to work with. Also, if an impl wanted to support auto-commit, it would be very intuitive, devs just wouldn't be required to start a transaction prior performing actions on a store. Thanks, - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksWCkMACgkQ9VpNnHc4zAyheACfY53gDNjZ4gqud8rqCPANk+O7 oJsAoIRaYfCjQK9gwaKCejPo76OBWbbE =Jcp0 -END PGP SIGNATURE-
