Re: Copy/Paste Events
I agree with Jacob. I find this part of the spec... puzzling. Since there is currently no way to differentiate between a copy and a dragstart, you could potentially cause unnecessary UI flicker if you added/changed elements during dragstart and removed them during dragend to make a visual indication that a drag was being performed. It seems that nobody has bothered to implement this part of the spec even when implementing Drag Drop so it must not make sense. The pragmatic approach would be to use something like that in IE or WebKit which are very similar. The difference being that, unlike IE, the WebKit model doesn't allow content to be arbitrarily added to the clipboard outside of the dedicated events - which I think is a good thing. Regards, Sebastian Markbåge On Mon, Jul 27, 2009 at 6:39 AM, Jacob Rossi t-jac...@microsoft.com wrote: Section 7.10.6 Copy and pastehttp://dev.w3.org/html5/spec/Overview.html#copy-and-pasteof the HTML5spec suggests that copy-and-paste is a form of drag-and-drop. It mandates that for a copy operation the user agent should act as if the user had initiated a drag on the current selection. Likewise, a cut should be a drag operation followed by a selection delete operation. Accordingly, a paste should be treated as a drop. I would assume this concept should be applied to the events associated with these actions as well. Thus it would follow that a copy/cut operation would produce a drag event and a paste would produce a drop. Is this really what we want? Most implementations (IE, Firefox, Safari, and Chrome) already have separate events for copy/cut/paste. While I see the similarities between the copy-and-paste and drag-and-drop, I don't believe that means they should be lumped together. For example, what if a web page wishes to change the mouse cursor while a drag operation is occurring? You wouldn't want the mouse cursor to change in the same manner when text is copied to the clipboard. In general, unless there is a significant savings in combining these two operations into one set of events, I think that they are best differentiated. Thoughts? Regards, Jacob Rossi
Re: Window Modes todo
On Jul 27, 2009, at 05:37 , Travis Leithead wrote: Adding WWW-DOM to widen the audience a bit. Having the attributes not be read only and allowing their modification before the Event is dispatched seems better to me. But changing this for DOM Events in general seems like a larger issue for discussion. Note that this is how it works in IE at the moment. It may be possible to make a change here for DOM L3 events, but we should take care as this would be a substantial change. Do other implementers care to chime in with what they do, and if they'd find this change acceptable? It's certainly somewhat large, but the initFooEvent methods really seem unwieldy to me, and if there's a chance to fix them I think we should. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
[widgets] Relationship of Widget viewmodes and OpenSocial view types
The OpenSocial spec also defines a set of views for gadgets[1] and I was wondering how these relate to Widget modes as defined in [2]. Here's a quick stab at relating the two specs: gadgets.views.ViewType.CANVAS = application (or fullscreen?) gadgets.views.ViewType.HOME = floating gadgets.views.ViewType.PREVIEW = (no equivalent; this seems to be like the old thumbnail/screenshot feature) gadgets.views.ViewType.PROFILE = floating (no equivalent) = mini/docked (come on, which is it guys?) On first glance its not a very elegant mapping! Partly this is because opensocial conflates the display and user role aspects (e.g. the distinction between Home and Profile is whether the viewer is typically the owner). Can/should the specs be easier to relate? Cheers, S [1] http://wiki.opensocial.org/index.php?title=Gadgets.views_(v0.9)#gadgets.views.ViewType [2] http://dev.w3.org/2006/waf/widgets-wm/Overview.src.html /-/-/-/-/-/ Scott Wilson Assistant Director, JISC CETIS University of Bolton Projects: Apache Wookie: http://incubator.apache.org/projects/wookie.html FeedForward: http://getfeedforward.org scott.bradley.wil...@gmail.com http://www.cetis.ac.uk/members/scott smime.p7s Description: S/MIME cryptographic signature
Re: Specs using Web IDL
On Sat, 27 Jun 2009 08:57:06 +0200, Cameron McCormack c...@mcc.id.au wrote: I’d like to know what specs are currently using Web IDL, so that I can keep abreast of what features are being used and help to review them. This is what I have so far: [...] Are there any others people are aware of? http://dev.w3.org/csswg/cssom-view/ I just updated it to reflect the new tricks. -- Anne van Kesteren http://annevankesteren.nl/
Re: Web IDL syntax
On Thu, 16 Jul 2009 12:16:00 +0200, Simon Pieters sim...@opera.com wrote: On Tue, 30 Jun 2009 09:07:22 +0200, Cameron McCormack c...@mcc.id.au wrote: Cameron McCormack: Following are my half baked proposals. I’ve now baked all of these proposals into the spec, except for the one about allowing multiple module levels with a module declaration (i.e., ‘module a::b::c’). * Made ‘in’ optional http://dev.w3.org/2006/webapi/WebIDL/#idl-operations Having it optional will likely lead to inconsistently written IDLs, which can be confusing. I think it would be better to either require it (as legacy cruft, basically) or remove it altogether (the relevant IDLs will need to be rewritten anyway for the other changes). +1 to removing cruft. (Also, I'd hate to add it back to CSSOM View at this point :-P) -- Anne van Kesteren http://annevankesteren.nl/
Re: Window Modes todo
Robin Berjon wrote: Do other implementers care to chime in with what they do, and if they'd find this change acceptable? As I recall Gecko's behavior, it works more or less like this: 1) Properties listed as readonly in the DOM 2 Events IDL are in fact readonly. 2) init*Event may be called multiple times, at any point when the event is not in the middle of being dispatched. 3) dispatchEvent may be called multiple times, at any point when the event is not in the middle of being dispatched. I believe #2 is a violation of the DOM 2 Events specification; I'm not quite sure why we allow that. I think there were some historical reasons, but they might not be relevant anymore. Olli might know more. The when the event is not in the middle of being dispatched for dispatchEvent is probably technically a violation of that specification too, though it's more likely that the issue was simply not considered during the authoring of the specification. -Boris P.S. I hope I understood the question correctly...
Re: Window Modes todo
For the JS framework MooTools, I'm currently implementing a model where you
can pass an object to an event constructor: new Event({ foo: 'bar', foo2:
'bar' });
Any uninitialized properties would fall back to defaults. This would be
comparable to named parameters found in many languages. You could also
compare this to IE's way of cloning an existing event if you pass one to
document.createEventObject.
However, this is very specific to the dynamic nature and object initializers
in JavaScript. So it's not suitable for this specification.
You could use multiple initializers - one for each section of functionality
or inheritance level.
To me, it doesn't make sense to add all the parameters from initEvent to
initUIEvent. A UIEvent inherits Event, so by definition it already has an
optional initializer (initEvent) that can take all those parameters.
DragEvent is pretty horrible:
initEvent(eventTypeArg, canBubbleArg, cancelableArg);
initUIEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg);
initMouseEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg,
screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg, altKeyArg,
shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg);
initDragEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg,
screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg, altKeyArg,
shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg, dataTransferArg);
Each step adds more stuff. It would be more flexible if each one in the
chain was called separately:
initEvent(eventTypeArg, canBubbleArg, cancelableArg);
initUIEvent(viewArg, detailArg);
initMouseEvent(screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg,
altKeyArg, shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg);
initDragEvent(dataTransferArg);
Implementations can already handle no init or a lower level init method
being called, in which case the higher level variables reverts to defaults.
But all of this is a very substantial change. One that I don't think is
necessary if there isn't a known need to change the lower level Event
interfaces. It might be that those properties need to allow setters anyway.
Sebastian Markbåge
On Mon, Jul 27, 2009 at 3:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Robin Berjon wrote:
Do other implementers care to chime in with what they do, and if they'd
find this change acceptable?
As I recall Gecko's behavior, it works more or less like this:
1) Properties listed as readonly in the DOM 2 Events IDL are in
fact readonly.
2) init*Event may be called multiple times, at any point when the
event is not in the middle of being dispatched.
3) dispatchEvent may be called multiple times, at any point when
the event is not in the middle of being dispatched.
I believe #2 is a violation of the DOM 2 Events specification; I'm not
quite sure why we allow that. I think there were some historical reasons,
but they might not be relevant anymore. Olli might know more. The when
the event is not in the middle of being dispatched for dispatchEvent is
probably technically a violation of that specification too, though it's more
likely that the issue was simply not considered during the authoring of the
specification.
-Boris
P.S. I hope I understood the question correctly...
Re: Web Storage how to check for support?
http://dev.w3.org/html5/webstorage/#the-storage-interface
Web Storage how to check for support?
How can one in a script check for UA support?
How about either of the following, they both worked as expected for me.
// Check for the Storage interface
if (window.Storage) { ... }
// Check for an instance of the interface
if (window.localStorage) { ... }
- Joe
Re: [widgets] Relationship of Widget viewmodes and OpenSocial view types
On Mon, Jul 27, 2009 at 3:40 PM, Scott Wilsonscott.bradley.wil...@gmail.com wrote: The OpenSocial spec also defines a set of views for gadgets[1] and I was wondering how these relate to Widget modes as defined in [2]. Here's a quick stab at relating the two specs: gadgets.views.ViewType.CANVAS = application (or fullscreen?) gadgets.views.ViewType.HOME = floating gadgets.views.ViewType.PREVIEW = (no equivalent; this seems to be like the old thumbnail/screenshot feature) gadgets.views.ViewType.PROFILE = floating (no equivalent) = mini/docked (come on, which is it guys?) On first glance its not a very elegant mapping! Partly this is because opensocial conflates the display and user role aspects (e.g. the distinction between Home and Profile is whether the viewer is typically the owner). Can/should the specs be easier to relate? I'm not sure yet... seems that they can happily live separately from each other. Those view types seem to serve practical roles/patterns, while W3C view modes are more like states of being/rendering states... so, a W3C mode can be in any view types listed above (e.g., fullscreen home, floating profile, etc.). -- Marcos Caceres http://datadriven.com.au
Re: Web Storage how to check for support?
Joseph,
thanks for that,
had tried document but not window
regards
~:
On 27 Jul 2009, at 16:41, Joseph Pecoraro wrote:
http://dev.w3.org/html5/webstorage/#the-storage-interface
Web Storage how to check for support?
How can one in a script check for UA support?
How about either of the following, they both worked as expected for
me.
// Check for the Storage interface
if (window.Storage) { ... }
// Check for an instance of the interface
if (window.localStorage) { ... }
- Joe
Re: [PC] utf8-char in Zip-rel-path
On Sun, Jul 26, 2009 at 11:29 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi, Given the fact that Rule names are case insensitive. http://tools.ietf.org/html/rfc5234#section-2.1 it could potentially be better to rename the rule from utf8-char to something else, since it may get confused with UTF8-char rule from http://tools.ietf.org/html/rfc3629#section-4. Taken into account my comments in the mail below, we could have new rule replacing utf8-char: zip-UTF8-char = UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = %xC2-DF UTF8-tail UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail ) UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail ) UTF8-tail = %x80-BF The problem may be with the allowed ranges of the Unicode characters. The above grammar seems to allow 0080-10 (the UTF-16 accessible range minus characters 0080) http://tools.ietf.org/html/rfc3629#section-3 whereas the current utf8-char rule is more selective. Unless it's broken (?), I would prefer to leave it as is. -- Marcos Caceres http://datadriven.com.au
Re: [PC] Low-level internationalization, XML deserialization, IRI or URI, IRI normalization
2009/7/25 Marcin Hanclik marcin.hanc...@access-company.com: Hi Marcos, All, Regarding the usage of IRI in the widget configuration document, I do not know which speicification is responsible for mandating the IRI normalization. It is possible that I simply have not yet found the proper existing explanation to the issue, so if you know it, I would be grateful to get this information. These are more details. The PC spec mixes the targets of the grammars (or low-level format specifications) it operates on. E.g. the sections about Zip archive operate on bytes http://www.w3.org/TR/widgets/#zip-archive http://www.w3.org/TR/widgets/#version-of-zip-needed-to-extract-a-file- and zip-rel-path grammar http://www.w3.org/TR/widgets/#zip-rel-path operates on characters, not bytes (it may not be fully clear from the PC text). XML Fifth Edition refers only to URI specification, it does not know about IRI. WUA must support XML and UTF-8: http://www.w3.org/TR/widgets/#dependencies-on-other-specifications-and The configuration document is only required to be XML: http://www.w3.org/TR/widgets/#configuration-document and its encoding may be virtually any that is registered with IANA (my assumption). So we can have the following situation: The WUA, that I develop widgets for, has a very interesting feature, whose IRI is really international (Polish in this case): http://example.com/ŁódzkiŚpiewnikŹdźbłowy I.e. the IRI contains characters outside of the US-ASCII character set. Then, I may not have an UTF-X capable editor at hand, so I convert the IRI to URI as in http://tools.ietf.org/html/rfc3987#section-3.1, Step 2. and I write the following config.xml with US-ASCII legacy encoding: ?xml version=”1.0” encoding=”us-ascii” widget … … feature name=”http://example.com/%C5%81%C3%B3dzki%C5%9Apiewnik%C5%B9d%C5%BAb%C5%82owy” / … /widget http://tools.ietf.org/html/rfc3987#section-3.2 provides a method to convert URI to IRI. However, I am not sure whether this conversion is mandated in PC, since PC just says that e.g. the name attribute is an IRI: I am not sure whether it should have IRI syntax in config.xml (not possible in my case, since I use US-ASCII only) or later. Percent encoding is allowed in IRIs: http://tools.ietf.org/html/rfc3987#section-2.2 and Terminals in the ABNF are characters, not bytes. Therefore it seems possible that the above config.xml, when parsed by XML- and UTF-8-supporting WUA, will refer to a feature whose IRI would be http://example.com/%C5%81%C3%B3dzki%C5%9Apiewnik%C5%B9d%C5%BAb%C5%82owy on the character level. Then, this valid IRI has to be checked for equivalence with http://example.com/ŁódzkiŚpiewnikŹdźbłowy based on the algorithm specified in http://tools.ietf.org/html/rfc3987#section-5.1 and http://tools.ietf.org/html/rfc3987#section-5.3.1 http://tools.ietf.org/html/rfc3987#section-5.3.2, specifically section 5.3.2.3 mentions percent-encoding normalization. I am not sure whether DOM3Core LoadSave mechanisms perform such normalization (as also below). PC does not specify it. PC says: An attribute defined as containing a valid IRI. A valid IRI is one that matches the IRI token of the [RFC3987] specification. Again, is it the syntax in config.xml (i.e. impossible on byte level) or later? DOM3Core http://www.w3.org/TR/DOM-Level-3-Core/core.html says A solution for loading a Document and saving it persistently is proposed in [DOM Level 3 Load and Save]. DOM3LS http://www.w3.org/TR/DOM-Level-3-LS/load-save.html will normalize the entities AFAIK, but probably will not normalize percent-encoded characters in URI/IRI. Proposal http://www.w3.org/TR/REC-xml-names/#iri-use says: Because of the risk of confusion between URIs that would be equivalent if dereferenced, the use of %-escaped characters in namespace names is strongly discouraged. So maybe PC shall state something similar, e.g. Because of the risk of confusion between IRIs that would be equivalent if dereferenced, the use of %-escaped characters in feature names is strongly discouraged. Yeah, that seems reasonable. I've added it. This could result in percent-encoded IRIs not be present in the configuration document, and the need for the configuration document developer to use UTF-8 capable editor (it may be too hard requirement, it is just a proposal). Alternatively, we could specify in PC that the attributes – that are currently specified as being IRI – shall actually be IRI or URI depending on the encoding of the config.xml. Third option would be to say something about IRI/URI normalization. More comments: The part of http://www.w3.org/html/wg/href/draft.html#parsing-urls namely: „How does this compare to just parsing using the IRI grammar of RFC 3987?” makes me think that the problem (I assume my problem and the Web addresses are similar) is not yet fully solved in any spec. I am sorry
Re: [WARP] @required attribute on access element
On Mon, Jul 20, 2009 at 6:41 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Dear All, Following the discussions (as below) about the topic of the required attribute on access element, I would like to provide a few comments to the current WARP WD. Historically access element was earlier in the widget set of specification than feature. From the design perspective the network access is a feature as are any other potential features (not specified in W3C yet, but coming in DAP), like messaging (SMS, MMS, any other means), file access etc. The semantic difference between access and feature is the missing @required attribute on access element. Removing from the below notes the following comments: - UX aspects, since they are the same as for feature - Policy aspects, for the same reason we could conclude that indeed @required could be put onto access element to uniformly treat functionalities/features and to prepare a consistent model - within all the widgets specifications - for any discussions around security policies in DAP. It seems that DAP may bring new inputs to the discussion about @required attribute, I just think that we may discuss it sooner so that the WARP spec ensures the consistency of the widget packaging data model. If possible, I would like to start a discussion about this topic over email, since the discussion during F2F (as below) seems to have diverted into undesired direction leaving the topic actually not fully clarified (either for or against). Following reasoning provided by Bryan Sullivan (e.g. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0489.html), my use case for @required attribute is as follows: Imagine a widget that is fully functional without network, e.g. an off-line game or MMS/SMS-client widget. The widget requires the network access only in very specific cases, e.g. to upload game result, and network access can easily fail, it is not mandatory for the normal operation of the widget. If the device/WUA has a policy specified (assuming W3C will define some, or e.g. as it is done within BONDI), the authority defining the policy may be interested in controlling the network access, due to e.g. roaming, similarly to controlling any other feature. The WARP spec says: For example, when a user attempts to install a Widget in a User Agent, and the Widget Configuration Document declares that it requires access to currently blocked services in order to function, the User Agent may prompt the user to choose to: 1. enable access to the service (for example, adding the service to a proxy server or firewall white list), 2. cancel installing the Widget, or 3. proceed with installation, with the user now aware that there may be problems with the Widget due to restricted access to services. Adding @required on access would change the state-machine related to widget. Currently if a widget requires network access, it is assumed that this access would be granted once forever, at installation time. It defaults to having @required=true. @required=false would mean - as for the above use case - that the widget does not have to access the network, it just may request such access. PC spec says the following about @required on access: When set to true, the required attribute denotes that a feature is absolutely needed by the widget to function correctly, and without the availability of this feature the widget serves no useful purpose or won't execute properly. When set to false, the required attribute denotes that a widget can function correctly without the feature being supported or otherwise made available by the user agent. The default value that a user agent must use when the required attribute is absent is true, meaning that the feature must be made available to the widget by the user agent at runtime. It is optional for authors to use the required attribute with an feature element. The intended semantics of the @required attribute on access would be exactly the same as in PC, thus there is potential for having a consistency. The PC spec no longer says any such thing. The PC is ignorant of access. To sum up, the most important argument for @required on access is the consistency of the model for feature and access elements. Thanks. Kind regards, Marcin Robin I'm happy to add a required attribute with the same semantics and processing as those of the same attribute on feature. I think it makes sense to be consistent here. Marcos I can live with this if the rest of the WG wants it, but I don't get the sense this will get used much (i.e., required = false'). So again, do we _REALLY_ need this? Bryan In the case of the resources identified by access, widgets may be designed to use a variety of them. As close to a specific example I can give (recognize that I expect the variety of widgets and their relationships to
Re: [widgets] removing onmodechange and viewMode from AE
On Tue, Jul 21, 2009 at 7:40 PM, Marcos Caceresmarc...@opera.com wrote: On Jul 21, 2009, at 7:27 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: +1 Sounds sensible - I've had a hard time figuring out what to do about these without the view modes spec being completed. I guess this is also good for UA that don't support view mode switching. Means that they can conform to AE I've removed them from the spec. -- Marcos Caceres http://datadriven.com.au
Treating persistent storage as cookies: mozilla safari
http://dev.w3.org/html5/webstorage/#user-tracking Treating persistent storage as cookies: mozilla safari anyone been able to clear localStorage via cookie preferences in mozilla or safari? regards Jonathan Chetwynd testcase: https://bug506639.bugzilla.mozilla.org/attachment.cgi?id=390836 however not found the relevant cookie in Safari, and minefield appears currently not to have a cookie manager ~:
Re: Treating persistent storage as cookies: mozilla safari
Marcos, I am quite well aware of the purported purposes of w3 lists, with somewhat over a decade's experience. however there are rather serious security and privacy concerns, and if the current UA implementations have not followed the specifications**, and these need to be fed back to the editors and authors to ensure updates and errata incorporate this possible failure. regards ~: ** as mentioned in the original email: User agents should present the persistent storage feature to the user in a way that does not distinguish them from HTTP session cookies. On 27 Jul 2009, at 18:09, Marcos Caceres wrote: Hi, This mailing list is for discussion of the spec, not implementations. Please find another list to have this discussion. Thanks! Marcos 2009/7/27 ~:'' ありがとうございました j.chetw...@btinternet.com: http://dev.w3.org/html5/webstorage/#user-tracking Treating persistent storage as cookies: mozilla safari anyone been able to clear localStorage via cookie preferences in mozilla or safari? regards Jonathan Chetwynd testcase: https://bug506639.bugzilla.mozilla.org/attachment.cgi?id=390836 however not found the relevant cookie in Safari, and minefield appears currently not to have a cookie manager ~: -- Marcos Caceres http://datadriven.com.au
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote: On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: It appears that Database, SQLTransactionCallback, SQLTransactionErrorCallback, SQLVoidCallback, SQLTransaction, SQLStatementCallback, and SQLStatementErrorCallback interfaces can all be eliminated from WebDatabase completely. Given WebWorkers and DatabaseSync, why do we need the Database object at all? Are there use cases that cannot be satisfied by the combination of the two that? All use cases are implementable with workers + synchronous databases given enough effort. This is really good to know. This likely means that the WG would be required to find strong reasons to keep the duplication. But using workers is a large burden: they are completely separate JavaScript environments that share nothing with the main web page. Having to use that for simpler use cases would be very unfortunate. I am not sure how large a burden this is. Can you quantify it? Can you explain why this would be unacceptable? If all we had was synchronous databases and you could only use them from workers, I think you'd immediately start seeing developers create JavaScript wrappers that look a lot like our current Database interface, because... If there is a good chance for a JavaScript library to thrive in this environment, then there is all the more reason for the WG to not bake in a required browser interface. There is a brand new programming model being promoted by the Database object, it is as complex as it gets and seriously I cannot get it. The current Database interface falls naturally out of the requirements: a. No IO on the UI thread b. Don't allow developers to forget to close transactions c. Support using databases from the JavaScript on web pages (don't require workers) If you can think of an alternate interface that meets these requirements, I'd love to hear it. But I suspect it will look very much like what we have. The programming model espoused by WebDatabase's async portion is that: 1. the programmer does all the SQL work in one or more asynchronous callbacks. 2. callbacks are always linear, however, the program performs its own stack management to keep the requisite context around for doing its processing inside asynchronous callbacks. If multiple calls to the database are required to perform certain work, then the programs become a chain of nested callbacks. 3. the only supported model of transaction isolation is serialization of all database access. This is certainly foreign to most database developers. Editors and/or others share the burden of proof that there is no alternative to this and that there is merit in standardizing a brand new programming model. Also, the programming model is not that novel. It is a straightforward application of IOC to ensure that transactions are always closed. Aaron misunderstands me here as I have no objection, per se, to IOC or RAII. The problem is with the rest of the programming model which he has not yet justified as having merit. Nikunj http://o-micron.blogspot.com
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, Jul 27, 2009 at 11:55 AM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote: On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: It appears that Database, SQLTransactionCallback, SQLTransactionErrorCallback, SQLVoidCallback, SQLTransaction, SQLStatementCallback, and SQLStatementErrorCallback interfaces can all be eliminated from WebDatabase completely. Given WebWorkers and DatabaseSync, why do we need the Database object at all? Are there use cases that cannot be satisfied by the combination of the two that? All use cases are implementable with workers + synchronous databases given enough effort. This is really good to know. This likely means that the WG would be required to find strong reasons to keep the duplication. But using workers is a large burden: they are completely separate JavaScript environments that share nothing with the main web page. Having to use that for simpler use cases would be very unfortunate. I am not sure how large a burden this is. Can you quantify it? Can you explain why this would be unacceptable? Well, Dimitri Glazkov wrote an emulation of HTML5 Database awhile ago on top of Gears. This is a piece of what a developer would have to do to emulate the async database interface on top of workers + a sync interface: http://code.google.com/p/html-5-sql-player It is about 3.5 kb, but all it does is emulate the async interface inside a worker using a synchronous backend. A real emulation of HTML5 async databases on top of HTML5 sync databases would have to do this, but move the async API out into the document context and put a marshalling layer between the two parts, with tracking of open transactions and statements on both sides. So doing a real emulation would be quite a bit more complex. Let's say you could do it in 7kb. For comparison, jquery compressed is 56k. That's an increase of 12.5%. A lot. I would guess that half of uses of the database API are simpler and the async interface would address their needs. As one humble example, my personal notepad site Gearpad (http://aaronboodman.com/gearpad) uses Gears local storage and it would work just fine on top of the async database interface. And the total code size of that site is 25 kb. It was designed specifically to be small and fast. Adding another 7kb for storage seems excessive. If all we had was synchronous databases and you could only use them from workers, I think you'd immediately start seeing developers create JavaScript wrappers that look a lot like our current Database interface, because... If there is a good chance for a JavaScript library to thrive in this environment, then there is all the more reason for the WG to not bake in a required browser interface. It is a balancing act. Taking this approach is what has led to the need for 56kb JavaScript libraries to do basic UI on the web. And even though getElementsByTagName(), as one example, works fine, we have gone and added getElementsBySelector(). Because it makes sense to centralize commonly needed functionality in the browser rather than have every app reimplement it. There is a brand new programming model being promoted by the Database object, it is as complex as it gets and seriously I cannot get it. The current Database interface falls naturally out of the requirements: a. No IO on the UI thread b. Don't allow developers to forget to close transactions c. Support using databases from the JavaScript on web pages (don't require workers) If you can think of an alternate interface that meets these requirements, I'd love to hear it. But I suspect it will look very much like what we have. The programming model espoused by WebDatabase's async portion is that: 1. the programmer does all the SQL work in one or more asynchronous callbacks. 2. callbacks are always linear, however, the program performs its own stack management to keep the requisite context around for doing its processing inside asynchronous callbacks. If multiple calls to the database are required to perform certain work, then the programs become a chain of nested callbacks. Yes, this is the model. Note that you only need to chain callbacks if you need to do javascript work after them. If you just need to do a bunch of statements, you can fire-and-forget and they will be queued. Or you can mix the two styles. 3. the only supported model of transaction isolation is serialization of all database access. This seems orthogonal to the discussion we're having, right? This is certainly foreign to most database developers. Editors and/or others share the burden of proof that there is no alternative to this and that there is merit in standardizing a brand new programming model. I can't speak to what most database developers will find foreign. Even though you work at a database company, I think it is hard for anyone to make generalization about what most of anyone
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 12:55 PM, Nikunj R. Mehta wrote:
On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote:
But using workers is a large burden: they are
completely separate JavaScript environments that share nothing with
the main web page. Having to use that for simpler use cases would be
very unfortunate.
I am not sure how large a burden this is. Can you quantify it? Can
you explain why this would be unacceptable?
The cost of using a Worker is that all interaction with the actual Web
page and its data is through an asynchronous channel that only allows
transfer of relatively simple pure data objects (essentially, JSON).
The advantage is that you can write database access as simple straight-
line code. If you want to do a lot of database work and don't need to
interact with page contents or associated JavaScript data structures
in the middle or very extensively, a Worker using the synchronous API
will likely work well. If you only want to do a little bit of database
access, or you need to mix it heavily with page interaction, using the
async API from the main thread will likely be simpler.
The programming model espoused by WebDatabase's async portion is that:
1. the programmer does all the SQL work in one or more asynchronous
callbacks.
2. callbacks are always linear, however, the program performs its
own stack management to keep the requisite context around for doing
its processing inside asynchronous callbacks. If multiple calls to
the database are required to perform certain work, then the programs
become a chain of nested callbacks.
3. the only supported model of transaction isolation is
serialization of all database access.
This is certainly foreign to most database developers. Editors and/
or others share the burden of proof that there is no alternative to
this and that there is merit in standardizing a brand new
programming model.
JavaScript actually lets you write a series of nested callbacks in a
way that looks almost like straight-line code, by using function
expressions:
db.transaction(function(tx) {
tx.executeSQL(SELECT UserID FROM Users WHERE UserName = ?,
[userToBan], function(tx, firstResultSet) {
if (resultSet.rows.length 0) {
tx.executeSQL(INSERT INTO BannedUsers VALUES (?),
resultSet.rows[0]);
}
}
});
(Sorry for the contrived example and my likely syntax errors.)
Granted, this gets awkward if your logic gets considerably more
complicated.
Regards,
Maciej
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 12:43 PM, Aaron Boodman wrote: On Mon, Jul 27, 2009 at 11:55 AM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote: On Fri, Jul 24, 2009 at 6:51 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: There is a brand new programming model being promoted by the Database object, it is as complex as it gets and seriously I cannot get it. The current Database interface falls naturally out of the requirements: a. No IO on the UI thread b. Don't allow developers to forget to close transactions c. Support using databases from the JavaScript on web pages (don't require workers) If you can think of an alternate interface that meets these requirements, I'd love to hear it. But I suspect it will look very much like what we have. The programming model espoused by WebDatabase's async portion is that: 1. the programmer does all the SQL work in one or more asynchronous callbacks. 2. callbacks are always linear, however, the program performs its own stack management to keep the requisite context around for doing its processing inside asynchronous callbacks. If multiple calls to the database are required to perform certain work, then the programs become a chain of nested callbacks. Yes, this is the model. Note that you only need to chain callbacks if you need to do javascript work after them. If you just need to do a bunch of statements, you can fire-and-forget and they will be queued. Or you can mix the two styles. 3. the only supported model of transaction isolation is serialization of all database access. This seems orthogonal to the discussion we're having, right? Yes, but I included it for completeness sake. This is certainly foreign to most database developers. Editors and/ or others share the burden of proof that there is no alternative to this and that there is merit in standardizing a brand new programming model. I can't speak to what most database developers will find foreign. Even though you work at a database company, I think it is hard for anyone to make generalization about what most of anyone will think about anything. On Jul 24, 2009, at 1:36 AM, Ian Hickson wrote: I think this is an important invariant, because otherwise script writers _will_ shoot themselves in the foot. These aren't professional database developers; Web authors span the gamut of developer experience from the novice who is writing code more by luck than by knowledge all the way to the UI designer who wound up stuck with the task for writing the UI logic but has no professional background in programing, let alone concurrency in databases. We can't be firing unexpected exceptions when their users happen to open two tabs to the same application at the same time, leaving data unsaved. The above text referred to a certain class of developers as being unable to cope with unexpected exceptions. Most Web authors are not experts at parsing specifications, I think you will agree. Database developers exist as a class. Most database developers are not UI programmers, I think you will agree. We all make generalizations and they are useful to a certain extent. They help us do language design, and I feel that one should identify the classes of developers and their readiness/preferences. The point is that database development is not new. There are already programming models available that people rely on for using applications in developing database-based applications. Why introduce yet another one? Just because someone proposed it and no one was interested in proposing another one? And we are talking here of standardizing one that is duplicating what can be achieved though JavaScript and much simpler, more conventional programming model. I think the odds are stacked against this one. What I can say is that given the requirements, this is the only interface I can imagine that works. I can also note that as a web developer, I didn't find this interface foreign. It is a bit unfortunate in the callbackyness, but I think it is a good tradeoff to be able to use databases without a worker. This design also has the advantage of having implementations in webkit and chromium so we at least know that it is implementable. Anything that is Turing complete, can be implemented. So what? Since when did the bar get lowered so much that only an existence proof is required? snip Also, the programming model is not that novel. It is a straightforward application of IOC to ensure that transactions are always closed. Aaron misunderstands me here as I have no objection, per se, to IOC or RAII. The problem is with the rest of the programming model which he has not yet justified as having merit. The merit is in that it meets the requirements and no other model does. It has already been confirmed that requirements were not adequately described for WebDatabase [1]. This argument is,
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 12:54 PM, Maciej Stachowiak wrote:
On Jul 27, 2009, at 12:55 PM, Nikunj R. Mehta wrote:
snip
JavaScript actually lets you write a series of nested callbacks in a
way that looks almost like straight-line code, by using function
expressions:
db.transaction(function(tx) {
tx.executeSQL(SELECT UserID FROM Users WHERE UserName = ?,
[userToBan], function(tx, firstResultSet) {
if (resultSet.rows.length 0) {
tx.executeSQL(INSERT INTO BannedUsers VALUES (?),
resultSet.rows[0]);
}
}
});
(Sorry for the contrived example and my likely syntax errors.)
Granted, this gets awkward if your logic gets considerably more
complicated.
And mine did get awkward, very quickly. I found it really hard to keep
myself sane through the development of asynchronous code that executes
transactionally and involves multiple sql statements.
My argument is that the program logic gets really complex, really fast
if you are doing anything complex using Database. On the other hand,
if your logic and SQL needs are really simple, you might as well use
the DatabaseSync interface and pay the price of marshaling and
unmarshaling, which may not be that much.
Alternatively, perhaps, we should consider doing something in
WebWorkers to deal with the overhead of sharing JavaScript objects
across VMs.
Nikunj
http://o-micron.blogspot.com
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote: And mine did get awkward, very quickly. I found it really hard to keep myself sane through the development of asynchronous code that executes transactionally and involves multiple sql statements. My argument is that the program logic gets really complex, really fast if you are doing anything complex using Database. On the other hand, if your logic and SQL needs are really simple, you might as well use the DatabaseSync interface and pay the price of marshaling and unmarshaling, which may not be that much. Aaron showed that it's pretty complex to implement the marshalling in a general way on top of Workers and a synchronous interface. Alternatively, perhaps, we should consider doing something in WebWorkers to deal with the overhead of sharing JavaScript objects across VMs. That would lead to far greater complexity for both implementations and content authors than the complexity saved by removing the async interface. Regards, Maciej
Re: Copy/Paste Events
On Mon, Jul 27, 2009 at 2:03 PM, Sebastian Markbågesebast...@calyptus.eu wrote: I agree with Jacob. I find this part of the spec... puzzling. so, one advantage of not distinguishing is that it enables people w/o mice to trigger drag events. if you don't do this, you effectively block such users from interacting with certain classes of web pages. Having encountered various other stupid forms of discrimination while working on devices which have limitations wrt input methods, i appreciate it when things are designed with more flexibility in mind. i'm not absolutely certain as to where i stand on this specific event, but i'm not immediately opposed to what Jacob quoted, and i respectfully request people to consider this. (I considered responding earlier and decided I'd wait.)
RE: Copy/Paste Events
timeless said: so, one advantage of not distinguishing is that it enables people w/o mice to trigger drag events. Do you have any data on how many people would be browsing with neither mouse nor touch capabilities? Are you mostly referring to non-touch mobile users? if you don't do this, you effectively block such users from interacting with certain classes of web pages. One possible solution is that copy-and-paste could be treated as drag-and-drop only when the browser is in Caret Browsing mode (do any browsers other than Firefox and IE have this?) and on mobile devices without touch capabilities. -Jacob -Original Message- From: timeless.b...@gmail.com [mailto:timeless.b...@gmail.com] On Behalf Of timeless Sent: Monday, July 27, 2009 3:54 PM To: Sebastian Markbåge Cc: Jacob Rossi; www-...@w3.org; public-webapps@w3.org; Travis Leithead; Tony Ross Subject: Re: Copy/Paste Events On Mon, Jul 27, 2009 at 2:03 PM, Sebastian Markbågesebast...@calyptus.eu wrote: I agree with Jacob. I find this part of the spec... puzzling. so, one advantage of not distinguishing is that it enables people w/o mice to trigger drag events. if you don't do this, you effectively block such users from interacting with certain classes of web pages. Having encountered various other stupid forms of discrimination while working on devices which have limitations wrt input methods, i appreciate it when things are designed with more flexibility in mind. i'm not absolutely certain as to where i stand on this specific event, but i'm not immediately opposed to what Jacob quoted, and i respectfully request people to consider this. (I considered responding earlier and decided I'd wait.)
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, Jul 27, 2009 at 2:32 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote: And mine did get awkward, very quickly. I found it really hard to keep myself sane through the development of asynchronous code that executes transactionally and involves multiple sql statements. My argument is that the program logic gets really complex, really fast if you are doing anything complex using Database. On the other hand, if your logic and SQL needs are really simple, you might as well use the DatabaseSync interface and pay the price of marshaling and unmarshaling, which may not be that much. Aaron showed that it's pretty complex to implement the marshalling in a general way on top of Workers and a synchronous interface. Also note that an API layered on top of Workers and a synchronous interface will still be an asynchronous API. / Jonas
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Jul 27, 2009, at 7:45 PM, Jonas Sicking wrote: On Mon, Jul 27, 2009 at 2:32 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote: And mine did get awkward, very quickly. I found it really hard to keep myself sane through the development of asynchronous code that executes transactionally and involves multiple sql statements. My argument is that the program logic gets really complex, really fast if you are doing anything complex using Database. On the other hand, if your logic and SQL needs are really simple, you might as well use the DatabaseSync interface and pay the price of marshaling and unmarshaling, which may not be that much. Aaron showed that it's pretty complex to implement the marshalling in a general way on top of Workers and a synchronous interface. Also note that an API layered on top of Workers and a synchronous interface will still be an asynchronous API. Understood. I am simply asking to not standardize something which can be easily implemented in JavaScript, until we understand the implications of the novel programming model being proposed. Nikunj http://o-micron.blogspot.com
Re: [WebDatabase] Database interface (vs. DatabaseSync interface)
On Mon, Jul 27, 2009 at 8:07 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jul 27, 2009, at 7:45 PM, Jonas Sicking wrote: On Mon, Jul 27, 2009 at 2:32 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote: And mine did get awkward, very quickly. I found it really hard to keep myself sane through the development of asynchronous code that executes transactionally and involves multiple sql statements. My argument is that the program logic gets really complex, really fast if you are doing anything complex using Database. On the other hand, if your logic and SQL needs are really simple, you might as well use the DatabaseSync interface and pay the price of marshaling and unmarshaling, which may not be that much. Aaron showed that it's pretty complex to implement the marshalling in a general way on top of Workers and a synchronous interface. Also note that an API layered on top of Workers and a synchronous interface will still be an asynchronous API. Understood. I am simply asking to not standardize something which can be easily implemented in JavaScript, until we understand the implications of the novel programming model being proposed. Like Aaron, I don't see that there is any other solution to the three requirements that he listed. Given that, I think it's appropriate that the API is designed as it is. (Note though that I'm not a fan of the SQL API in general as I think SQL is the wrong tool here, hope to have an alternative proposal eventually). Designing APIs for the web is different from designing APIs for many other platforms. The fact that the resulting API comes out differently than elsewhere is not I think we can avoid. / Jonas
