Re: Proposal for addition to WebStorage
BITSY is offered as a complementary technique for WebStorage not as a replacement to SQL. On Apr 24, 2009, at 4:03 PM, Ian Hickson wrote: On Fri, 24 Apr 2009, Nikunj Mehta wrote: We want to standardize interception of HTTP requests inside Web browsers so as to allow applications to do their own interception and seamlessly access data on-line and off-line. This is primarily targeted at improving availability of data used by Web applications and improve their responsiveness. How would you implement an offline Web mail client with such a mechanism? I know how to implement a business application using this technique, sorry I don't claim too much familiarity with Web mail. In particular, how would you maintain the "read"/"unread" state of individual e-mail messages, or move e-mails between folders as the user drags them around, or search for messages from a particular user received between a set of dates? Each message has a network representation, and a URL to go along. So while you are manipulating its attributes, you are essentially updating that representation. Of course, you can build a structured database (possibly accessed using SQL) to enable the navigation and query mechanisms you are interested in. This database can be maintained by the proposed interceptors, thus creating a database that is only read by applications and updated by the synchronization library. All updates to data are seen as network requests as opposed to SQL UPDATE statements.
Re: Web Storage & SQL
On Apr 17, 2009, at 2:39 PM, Jonas Sicking wrote: On Tue, Apr 14, 2009 at 9:08 AM, Nikunj Mehta wrote: On Apr 11, 2009, at 12:39 AM, Jonas Sicking wrote: On Fri, Apr 10, 2009 at 10:55 PM, Nikunj Mehta > wrote: On Apr 10, 2009, at 3:13 PM, Ian Hickson wrote: On Fri, 10 Apr 2009, Nikunj Mehta wrote: Can someone state the various requirements for Web Storage? I did not find them enunciated anywhere. There's only one requirement that I know of: * Allow Web sites to store structured data on the client. There are many use cases, e.g. Google is interested in this to enable its applications to be taken offline. We recently released offline GMail using this SQL backend; one could easily imagine other applications like Calendar, Reader, Docs&Spreadsheets, etc, supporting offline mode. A while back we released a demo of Reader using Gears' SQL database. Last time I tried this trick I was asked to come back with more precise use cases [1]. Then I put together more detailed use cases [2], and even those were not considered to be written precisely enough. So it looks like the bar for what constitutes a use case or requirement seems to be quite high. [1] http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0079.html [2] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0104.html As far as I am concerned the use cases you enumerate in [2] were fine. However note that even the current WebStorage API makes it possible to address those use cases. Just in a way that is vastly different than the solution that you propose in [2]. Do you not agree? WebStorage does not, or for that matter any other speced API, make it possible to intercept PUT/POST/DELETE requests to perform offline behavior that can be later synchronized to the server. Indeed. But it does make it technically possible to address the use cases that you listed. Not it doesn't and that is why I have offered the BITSY proposal. http://www.oracle.com/technology/tech/feeds/spec/bitsy.html I think the main road block to accepting something like that is simply needing more experience in the WG. Since your requirement, or at least your proposed solution, require that the standard design how the synchronization should work, I personally would like to know more about other synchronization technologies before accepting your proposal. I have been working to simplify the requirements to allow application-specified synchronization provided: 1. The browser stores/caches certain URLs à la Gears LocalServer and the browser responds to GET/HEAD requests for those URLs 2. The browser allows JS interception of requests for non-GET/HEAD requests to certain URLs 3. The browser enforces cookie requirements for accessing those URLs 4. The browser provides some structured storage JS API for storing synchronization state (not the contents of the data itself) 5. The browser provides JS to contribute content to the browser store/cache as text (or blob) So it's entirely the responsibility of JS to synchronize the data? Using whatever means already exist, such as XHR etc? Nothing tied to AtomPub at all? This is correct. You can see this from the proposal. We have a JS library to synchronize AtomPub data, but this is completely optional. So it has nothing to do with lack of use cases, much more to do with that we're designing a different very API, and so we need different expertise and background data. At this point, the API that is required for BITSY is far simpler than it used to be - you can just think of it as a couple of extra methods to the Gears LocalServer API. That means we have a fair amount of expertise within this WG - both Google and Oracle have toyed with slightly different parts of this problem. Oracle has implemented the browser mechanisms above as a plug-in for both Safari and Firefox. Oracle can provide this specification as a member submission if that helps the WG. Of course in order to be able to evaluate a proposal we have to see it :) Hope to see a constructive discussion now that you can see it. [snip]
Re: Proposal for addition to WebStorage
On Fri, 24 Apr 2009, Nikunj Mehta wrote: > > We want to standardize interception of HTTP requests inside Web browsers > so as to allow applications to do their own interception and seamlessly > access data on-line and off-line. This is primarily targeted at > improving availability of data used by Web applications and improve > their responsiveness. How would you implement an offline Web mail client with such a mechanism? In particular, how would you maintain the "read"/"unread" state of individual e-mail messages, or move e-mails between folders as the user drags them around, or search for messages from a particular user received between a set of dates? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Fwd: [whatwg] Exposing EventTarget to JavaScript
Forwarded from whatwg upon Ian's request.
Forwarded conversation
Subject: Exposing EventTarget to JavaScript
From: *Erik Arvidsson*
Date: Fri, Apr 24, 2009 at 10:00
To: whatwg
Almost all JavaScript libraries and web apps of moderate size end up
reimplementing events for their UI toolkits or for messaging between
different parts of their application. To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript. This would mean that JavaScript can
instantiate and extend event targets and dispatch events to these
objects would work just like it does for DOM elements today.
For example:
var et = new EventTarget;
...
et.addEventListener('foo', fun, false);
...
et.dispatchEvent(eventObject);
would call the handler fun.
The example above actually works today if you replace "new
EventTarget" with "document.createElement('div')".
The next and more important step is to allow a JavaScript "class" to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
Then addEventListener and dispatchEvent should work as expected on
MyClass objects.
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a "parentNode" property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow "new Event('foo')" to work.
Without that we would still have to do "var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo')" which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that "this is the beginning of a beautiful friendship".
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
--
From: *Kristof Zelechovski*
Date: Fri, Apr 24, 2009 at 10:17
To: Erik Arvidsson , whatwg <
wha...@lists.whatwg.org>
As a reminder, the syntax {new Option()} (Netscape DOM) is deprecated to the
syntax {document.createElement("OPTION")} (W3C DOM). The requested syntax
{new Event()} would be inconsistent with that design decision. OTOH, the
syntax {new XMLHTTPRequest()} has already been adopted, perhaps because
{document.createXMLHTTPRequest()} would be too specific?
A bit confused,
Chris
--
From: *Alex Russell*
Date: Fri, Apr 24, 2009 at 10:29
To: Erik Arvidsson
Cc: whatwg
As we discussed off-list, I absolutely support this, but with shorter
names. The DOM names for these interfaces are dumb. Idiomatic JS
prefers short over long, so the above example should be able to be
written as:
var et = new EventTarget();
et.listen("foo", fun); // default phase to "false"
et.dispatch(evtObj);
Similarly, the DOM interface should be modified to allow these aliases
for the existing names.
Regards
--
From: *Giovanni Campagna*
Date: Fri, Apr 24, 2009 at 10:30
To: Erik Arvidsson
Cc: whatwg
2009/4/24 Erik Arvidsson :
This should not work. This is because the DOM event system (used for
elements) is different from the scripting event system (used for
windows, xmlhttprequest, workers, etc.). The former requires a
document through which the event flows (capture - target - bubble
phases). No document => no event.
This is a matter of host language, not of DOM. In Java, you just do
public class MyClass implements EventTarget {
}
and the same in ES6 (ES-Harmony)
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
Giovanni
--
From: *Alex Russell*
Date: Fri, Apr 24, 2009 at 10:33
To: Giovanni Campagna
Cc: Erik Arvidsson , whatwg <
wha...@lists.whatwg.org>
This is a bug, not a design constraint.
JavaScript should be extended to support event dispatch (as Erik
outlines) and it should be done in such a way as to cast the DOM event
system as an implementation of that dispatch mechanism. Suggesting
that JS and DOM shouldn't be more tightly integrated because they
havent' been more tightly integrated in the past isn't a legit
argument.
It's safe to fully ignore Java.
Regards
--
From: *Ojan Vafai*
Date: Fri, Apr 24, 2009 at 10:55
To: Erik Arvidsson , Alex Russell <
slightly...@google.com>
I think we should wait for another day's worth of feedback and then try to
get WebKit teams' thoughts on this. If they agree that this is a good idea,
we can just add it to WebKit-based browsers and thats the end of the
discussion really.
Alex, while I agree that the naming is unfortunate, I'm of the opinion that
we're stuck with it for now.
Re: addEventListener naming
Hi, Alex-
Alex Russell wrote (on 4/24/09 5:31 PM):
The DOM function "addEventListener" is probably too long. It should,
instead, be named something much shorter owing to the amount of
exercise it receives. Further, it should default the last parameter to
be "false" (non-capture-phase). This call:
node.addEventListener("click", function(e) { /* ... */ }, false);
Should be able to be written as (e.g.):
node.listen("click", function(e) { /* ... */ });
Similarly, "removeEventListener" should be aliased as "unlisten". As a
further help, the common-case operation of listening-for-a-single-call
is currently written as:
var h = function(e) {
/* */
node.removeEventListener(h);
};
node.addEventListener("click", h);
And given how common this operation it, it should probably have an alias:
node.listenOnce("click", function(e) { /* ... */ });
Obviously, we can't get rid of "addEventListener" or
"removeEventListener". In the past, we've had pushback from browser
vendors that event aliasing is frowned upon.
Personally, I'm fine with your suggestion, and I'd be fine with putting
it into DOM3 Events on the EventTarget interface. Here are some of the
challenges that would need to be overcome:
1) browser implementers would have to sign off on it, and commit to
putting it into browsers
2) "event aliasing" would need to be better defined (maybe... if we
introduced it simply as a new method, and don't dig into the rathole
about what "event aliasing" is, that would be fine with me)
3) what would we do for older browsers that don't understand the new
method? Script libs are great, but only take us so far... if people
have to use a script lib to use "listen()", then why change it in the
first place, when it can be aliased in the script lib anyway? (I'm not
arguing against it, just raising the issue... maybe the answer is: "Make
people upgrade their browsers to use new technology." ^_^ )
I like your idea of "listenOnce()". Would that also be removed by
"unlisten()" in case the author wanted to cancel it, or would it require
its own remover? Is it worth thinking about simply adding an optional
parameter to el.listen( "evtname", function(e) {},
number-of-times-to-listen )? (Probably not.) Listing some use cases
for it might help this along.
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
[webstorage] storage event should be dispatched async
The storage event currently seems to be dispatched synchronously. Together
with the storage mutex this easily creates a deadlock:
Window A (origin x):
localStorage.x = "foo"
Window B (origin x):
onstorage = function(e) { print(localStorage.x) }
We think it should be dispatched asynchronously therefore.
--
Anne van Kesteren
http://annevankesteren.nl/
[webstorage] fork bombing
We noticed a problem while working on Web Storage. The broadcasting feature allows fork bombing. I personally couldn't think of any other features that allows such a thing. Works against Gecko: http://dump.testsuite.org/2009/storage/demo-001.htm Works against WebKit: http://dump.testsuite.org/2009/storage/demo-001-webkit.htm Internet Explorer seems protected against this particular demo increasing only a slightly in memory usage (though a lot of I/O): http://dump.testsuite.org/2009/storage/demo-001-trident.htm Should we really be introducing such a new feature (broadcasting) as part of sessionStorage/localStorage? -- Anne van Kesteren http://annevankesteren.nl/
addEventListener naming
>From this thread on whatwg:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019379.html
and per Hixie's request that I re-direct this particular discussion here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019381.html
The DOM function "addEventListener" is probably too long. It should,
instead, be named something much shorter owing to the amount of
exercise it receives. Further, it should default the last parameter to
be "false" (non-capture-phase). This call:
node.addEventListener("click", function(e) { /* ... */ }, false);
Should be able to be written as (e.g.):
node.listen("click", function(e) { /* ... */ });
Similarly, "removeEventListener" should be aliased as "unlisten". As a
further help, the common-case operation of listening-for-a-single-call
is currently written as:
var h = function(e) {
/* */
node.removeEventListener(h);
};
node.addEventListener("click", h);
And given how common this operation it, it should probably have an alias:
node.listenOnce("click", function(e) { /* ... */ });
Regards
Re: Storage and widgets
In our system when a widget is instantiated we generate our own instance hashes which we append to the widget URL as a parameter, and our Storage implementation uses this parameter when it needs to make a request back to our prefs web service to load preferences, or to set a preference. I imagine any UA would put a similar mechanism in place in its Storage implementation to sandbox the preferences for widget instances; does that need to be specified? On 24 Apr 2009, at 09:37, Arve Bersvendsen wrote: On Thu, 23 Apr 2009 20:17:07 +0200, Thomas Roessler wrote: Guido Grassel is reminding me that the HTML5 storage API keys off origin. Thy means another wrinkle or the uri scheme/origin discussion. Note that only the instantiations of storage, through the localStorage and sessionStorage, are using origin. The storage interface itself does not, so I do not see any immediate consequences with regards to preferences or any uri scheme discussion. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
RE: New Widgets A&E Editors Draft
Dear Arve, Here are my comments on your Widgets A&E last editor's draft. 1. Change "A environment in which a Widget interface is presented to the user." to "An environment in which a Widget interface is presented to the user." 2. All URLs in the "Step 8" hyperlinks in section "The Widget Interface" have a backslash at the end. 3. Section "The Widget Interface", definitions of "viewMode" to "version" attributes: e.g. "Upon instantiation, this attribute MUST be set to the value of widget window mode, which is derived from the configuration defaults from processing the configuration document in the [Widgets-Packaging] specification (Step 8)." In step 3 of [Widgets-Packaging], a user agent must assume the defined default values. In step 7, the configuration document is processed. So, "Step 8" seems to be the wrong step. According to my understanding, when a widget uses the Widget interface, step 3 and step 7 were already processed. This means the return value is either the default value or the value that was set in the configuration document. Isn't it the case for all readonly attributes? Only the definition of the identifier attribute contains the "if one was used in the configuration document" condition. What would you think about a definition like "The identifier attribute represents the value of widget element's id attribute, if one was used in the configuration document ([Widgets-Packaging], Step 7). Otherwise, this attribute MUST be set to the value of widget id, which is derived from the configuration defaults from processing the widget resource in the [Widgets-Packaging] specification (Step 3)." which could be easily reused for the other readonly attribute definitions? 4. Section "The Widget Interface": "The authorName attribute represents the name of the person who authored the widget." According to the current P&C, an "author element represents people or an organization attributed with the creation of the widget." So, authorName will not always contain the widget's author name. It could also be the name of an organisation or a company. I would like to propose changing "The authorName attribute represents the name of the person who authored the widget." to "The authorName attribute represents people or an organization attributed with the creation of the widget." 5. Section "The Widget Interface": Change "[...] configuration document as specified in [Widgets]." to "[...] configuration document as specified in [Widgets-Packaging]." 6. Section "The Widget Interface": Change "The onmodechange attribute MAY hold a a function that is [...]" to "The onmodechange attribute MAY hold a function that is [...]". 7. Section "The onmodechange Callback": This section contains the term "currentMode" two times. However, this attribute is not defined. It can't be "viewMode" because viewMode is either the default value from P&C Step 3 or the value from P&C Step 7. Best Regards, Rainer * T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: rainer.hillebr...@t-mobile.net http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
public-webapps@w3.org
I agree. - No exception to maintain coherence. - Name "changeMode()". Arve> It should be noted, however, that this is problematic on device for a number of reasons, > given that floating or mini widgets would typically exist on some "desktop" > or in an application > grid, so these mode changes are problematic from a UX-view (and may as well > have a security implication or two) Can you word this a bit more? I'm not sure I get what you mean here. Regards --- Ivan De Marino Orange Labs Mobile and Web Software Engineer, R&D UK tel. +44 20 8849 5806 mob. +44 7515 955 861 mob. +44 7974 156 216 ivan.demar...@orange-ftgroup.com This e-mail, and any files transmitted with it, is intended only for the use of the person/s or entity to whom it is addressed. If you are not the intended recipient (or authorised to receive information for the intended recipient) you must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and delete all copies of this e-mail. Thank you. France Telecom R&D UK Ltd is a company registered in England and Wales with company number 4193379. Our registered office is Minerva House, Montague Close, London, SE1 9BB. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: 24 April 2009 12:37 To: Arve Bersvendsen Cc: DE MARINO Ivan RD-ILAB-LON; public-webapps@w3.org; zze-Igloo ALI M ext RD-ILAB-LON; UDDIN Rafel RD-ILAB-LON Subject: Re: [Proposal] Empowering the Widget to ask fro "mode change" in A&E On Fri, Apr 24, 2009 at 1:25 PM, Arve Bersvendsen wrote: > On Fri, 24 Apr 2009 13:21:15 +0200, Marcos Caceres wrote: > >>> In that case, it is not a request, so widget.changeMode() >>> would be more appropriate, where a user agent MAY choose to not >>> honor the request. >>> >> >> If it doesn't, it would throw an exception. Right? > > I would much prefer that it didn't, were we to specify this, as it > would be consistent with other APIs for managing windows and sizes: > window.open() never throws, neither does > resizeTo|resizeBy|moveTo|moveBy > Ok, that makes sense. -- Marcos Caceres http://datadriven.com.au
[webstorage] events
There's quite a big interoperability problem with the events. * Per the specification the event is to be dispatched on Window (and does not bubble). * In Firefox it is dispatched on body and then bubbles up to Window. * In WebKit it is dispatched on body (and does not bubble). * In Internet Explorer it is dispatched on document. It would be nice if we can figure out where we want to go in the end. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widget-digsig] Updated Widget Signature editors draft
how about this: Note that with an optional algorithm interoperability may not always be possible if user agents have not implemented it. Implementation of this algorithm is encouraged since it can become mandatory in a subsequent release of this specification, and this may become necessary if a security issue is discovered with the currently required algorithm. regards, Frederick Frederick Hirsch Nokia On Apr 24, 2009, at 5:20 AM, ext Priestley, Mark, VF-Group wrote: "I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents." Agreed - in fact I think a general statement about use of optional algorithms would be beneficial -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org ] On Behalf Of Marcos Caceres Sent: 24 April 2009 09:46 To: Frederick Hirsch Cc: Web Applications Working Group WG Subject: Re: [widget-digsig] Updated Widget Signature editors draft Hi Frederick, Thanks for updating the spec! comment below. On Fri, Apr 24, 2009 at 3:14 AM, Frederick Hirsch > wrote: I have updated the Widget Signature draft to reflect decisions on today's call, as follows: Added ECDSAwithSHA256 as SHOULD signature algorithm I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents. Removed editor notes re feedback on signature algorithms Removed editor note with Signature Properties reference, since we've removed section 9 Added FIPS-186-3 reference http://dev.w3.org/2006/waf/widgets-digsig/ Note that we will need to update the Signature Properties reference, when that specification is published with this specification. regards, Frederick Frederick Hirsch Nokia -- Marcos Caceres http://datadriven.com.au
public-webapps@w3.org
On Fri, Apr 24, 2009 at 1:25 PM, Arve Bersvendsen wrote: > On Fri, 24 Apr 2009 13:21:15 +0200, Marcos Caceres wrote: > >>> In that case, it is not a request, so widget.changeMode() >>> would be more appropriate, where a user agent MAY choose to not honor >>> the request. >>> >> >> If it doesn't, it would throw an exception. Right? > > I would much prefer that it didn't, were we to specify this, as it would be > consistent with other APIs for managing windows and sizes: window.open() > never throws, neither does resizeTo|resizeBy|moveTo|moveBy > Ok, that makes sense. -- Marcos Caceres http://datadriven.com.au
Re: Storage and widgets
On 24 Apr 2009, at 13:19, Marcos Caceres wrote: We need to figure out what the baseline policy is for access to persistent storage that is shared across several instances, or even several widgets. Agreed. We are unsure if that goes into our spec or into the WebStorage spec. I suspect there is a piece of it that ought to go into the Widget spec. The current approach simply means that there is no shared, persistent storage in the widget model; that's probably isn't what people desire. "the current approach" meaning what is currently specified in the A&E spec, right? It means what's currently in the web storage spec, and what's in every way to construct an origin for a widget that I've seen -- whether it's Arve's approach with the widget:// scheme (and some random string in it, per instance), or my proposal of simply going for a random string.
public-webapps@w3.org
On Fri, 24 Apr 2009 13:21:15 +0200, Marcos Caceres wrote: >> In that case, it is not a request, so widget.changeMode() >> would be more appropriate, where a user agent MAY choose to not honor >> the request. >> > > If it doesn't, it would throw an exception. Right? I would much prefer that it didn't, were we to specify this, as it would be consistent with other APIs for managing windows and sizes: window.open() never throws, neither does resizeTo|resizeBy|moveTo|moveBy -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
public-webapps@w3.org
On Fri, Apr 24, 2009 at 12:36 PM, Arve Bersvendsen wrote: > On Fri, 24 Apr 2009 12:26:29 +0200, wrote: > >> Hello guys. >> >> What would you think of an API for empowering the Widget to "ask for >> mode change"? >> Something like: >> widget.ModeChangeRequest(); >> >> Of course the WUA can ignore the request. > > In that case, it is not a request, so widget.changeMode() would be > more appropriate, where a user agent MAY choose to not honor the request. > If it doesn't, it would throw an exception. Right? > It should be noted, however, that this is problematic on device for a number > of reasons, given that floating or mini widgets would typically exist on some > "desktop" or in an application grid, so these mode changes are problematic > from a UX-view (and may as well have a security implication or two) > Agreed. -- Marcos Caceres http://datadriven.com.au
Re: Storage and widgets
On Fri, Apr 24, 2009 at 11:51 AM, Thomas Roessler wrote: > On 24 Apr 2009, at 10:54, Marcos Caceres wrote: > >> It would be really helpful if you could enumerate these complexities, >> please? > > What I'm proposing currently (and I think other proposals are having the > same effect) implies that there is a new and separate origin every time a > widget is newly instantiated. The baseline policy that this corresponds to > (and which could be relaxed later on) is the rough equivalent to each widget > being a sandboxed iframe. This is correct and what we (the editors) had assumed (though not specified). > We need to figure out what the baseline policy is for access to persistent > storage that is shared across several instances, or even several widgets. Agreed. We are unsure if that goes into our spec or into the WebStorage spec. > The current approach simply means that there is no shared, persistent > storage in the widget model; that's probably isn't what people desire. "the current approach" meaning what is currently specified in the A&E spec, right? > Does this help? Lots :) Thanks Thomas. -- Marcos Caceres http://datadriven.com.au
public-webapps@w3.org
On Fri, 24 Apr 2009 12:26:29 +0200, wrote: > Hello guys. > > What would you think of an API for empowering the Widget to "ask for > mode change"? > Something like: > widget.ModeChangeRequest(); > > Of course the WUA can ignore the request. In that case, it is not a request, so widget.changeMode() would be more appropriate, where a user agent MAY choose to not honor the request. It should be noted, however, that this is problematic on device for a number of reasons, given that floating or mini widgets would typically exist on some "desktop" or in an application grid, so these mode changes are problematic from a UX-view (and may as well have a security implication or two) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Storage and widgets
On 24 Apr 2009, at 10:54, Marcos Caceres wrote: It would be really helpful if you could enumerate these complexities, please? What I'm proposing currently (and I think other proposals are having the same effect) implies that there is a new and separate origin every time a widget is newly instantiated. The baseline policy that this corresponds to (and which could be relaxed later on) is the rough equivalent to each widget being a sandboxed iframe. We need to figure out what the baseline policy is for access to persistent storage that is shared across several instances, or even several widgets. The current approach simply means that there is no shared, persistent storage in the widget model; that's probably isn't what people desire. Does this help?
Re: Web Storage Scope and Charter
On Fri, 24 Apr 2009 08:32:31 +0200, Nikunj Mehta wrote: On Apr 23, 2009, at 1:47 PM, Anne van Kesteren wrote: FWIW, Opera is primarily interested in implementing the APIs currently in the specification (including the SQL API). Specifying the specifics of the SQL dialect in due course would be good though, but doing that does not seem very controversial and I would assume is a requirement for going to Last Call. I am puzzled that you feel that specifying the semantics for the SQL dialect would be straightforward. I didn't say it would be straightforward. It might be, but I really wouldn't know. We have no experience of using more than a single database implementation for WebStorage. Its kind of interesting that the WG is attempting to standardize that which has no more than a single implementation. The draft specification was there before the implementation and there's a plug-in implementation (Gears) as well. It sees better to coordinate new APIs then to end up with four incompatible ones. -- Anne van Kesteren http://annevankesteren.nl/
RE: [widget-digsig] Updated Widget Signature editors draft
"I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents." Agreed - in fact I think a general statement about use of optional algorithms would be beneficial -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: 24 April 2009 09:46 To: Frederick Hirsch Cc: Web Applications Working Group WG Subject: Re: [widget-digsig] Updated Widget Signature editors draft Hi Frederick, Thanks for updating the spec! comment below. On Fri, Apr 24, 2009 at 3:14 AM, Frederick Hirsch wrote: > I have updated the Widget Signature draft to reflect decisions on > today's call, as follows: > > Added ECDSAwithSHA256 as SHOULD signature algorithm I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents. > Removed editor notes re feedback on signature algorithms Removed > editor note with Signature Properties reference, since we've removed > section 9 Added FIPS-186-3 reference > > http://dev.w3.org/2006/waf/widgets-digsig/ > > Note that we will need to update the Signature Properties reference, > when that specification is published with this specification. > > regards, Frederick > > Frederick Hirsch > Nokia > > > > > -- Marcos Caceres http://datadriven.com.au
public-webapps@w3.org
On Apr 24, 2009, at 11:12 , Marcos Caceres wrote: Also note that a scheme doesn't necessarily uniquely map to a protocol, so it should probably say "scheme handler". Right. I thought the same thing. I used "protocol handler" to be consistent with HTML5. Ah, well before we use different terminology we should have a chat with someone who knows where that wording comes from in HTML5 and see if there's a reason to keep it. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
public-webapps@w3.org
On Thu, Apr 23, 2009 at 2:26 PM, Robin Berjon wrote: > On Apr 23, 2009, at 12:36 , Marcos Caceres wrote: >>> >>> 3. [User Agents] "A user agent is an implementation" a bit vague. Perhaps >>> some of the text in the following note should be move here, to refine the >>> definition. >> >> I changed it to "A user agent is software that implements the >> application programming interfaces defined in this specification. A >> user agent must behave as described by this specification in order to >> claim conformance." > > I can't seem to dig it up right now, but IIRC there's something in the QA > documents that defines this which can be reused. > >>> 15. [The openURL() Method] Why couldn't this be generalised to open URI, >>> including mailto:, tel: and more? >>> >> Right: changed it to: >> >> "The openURL(url) method takes a valid URI as an argument. When >> invoked, the url should be opened with the appropriate protocol >> handler for the given URI. If there is no such protocol handler or >> urlis not a valid URI, then the user agent must act as if the method >> was not invoked.." > > Should we make it clear that the UA is allowed to ask the user for a handler > for a given scheme? > > Also note that a scheme doesn't necessarily uniquely map to a protocol, so > it should probably say "scheme handler". Right. I thought the same thing. I used "protocol handler" to be consistent with HTML5. -- Marcos Caceres http://datadriven.com.au
Re: Storage and widgets
Hi Thomas, On Fri, Apr 24, 2009 at 10:48 AM, Thomas Roessler wrote: > The implication is twofold: > > 1. If widgets are to use one of these storage mechanisms, then we need to > say what (instead of origin) the storage is scoped by, and how a widget > acquires an instance. This is true. > 2. As far as security policies are concerned, this suggests that we are > acquiring an additional set of complexity earlier than I had thought. It would be really helpful if you could enumerate these complexities, please? -- Marcos Caceres http://datadriven.com.au
Re: Storage and widgets
The implication is twofold: 1. If widgets are to use one of these storage mechanisms, then we need to say what (instead of origin) the storage is scoped by, and how a widget acquires an instance. 2. As far as security policies are concerned, this suggests that we are acquiring an additional set of complexity earlier than I had thought. -- Thomas Roessler, W3C (mobile) On Apr 24, 2009, at 10:37, "Arve Bersvendsen" wrote: On Thu, 23 Apr 2009 20:17:07 +0200, Thomas Roessler wrote: Guido Grassel is reminding me that the HTML5 storage API keys off origin. Thy means another wrinkle or the uri scheme/origin discussion. Note that only the instantiations of storage, through the localStorage and sessionStorage, are using origin. The storage interface itself does not, so I do not see any immediate consequences with regards to preferences or any uri scheme discussion. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widget-digsig] Updated Widget Signature editors draft
Hi Frederick, Thanks for updating the spec! comment below. On Fri, Apr 24, 2009 at 3:14 AM, Frederick Hirsch wrote: > I have updated the Widget Signature draft to reflect decisions on today's > call, as follows: > > Added ECDSAwithSHA256 as SHOULD signature algorithm I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents. > Removed editor notes re feedback on signature algorithms > Removed editor note with Signature Properties reference, since we've removed > section 9 > Added FIPS-186-3 reference > > http://dev.w3.org/2006/waf/widgets-digsig/ > > Note that we will need to update the Signature Properties reference, when > that specification is published with this specification. > > regards, Frederick > > Frederick Hirsch > Nokia > > > > > -- Marcos Caceres http://datadriven.com.au
Re: Storage and widgets
On Thu, 23 Apr 2009 20:17:07 +0200, Thomas Roessler wrote: > Guido Grassel is reminding me that the HTML5 storage API keys off > origin. Thy means another wrinkle or the uri scheme/origin discussion. Note that only the instantiations of storage, through the localStorage and sessionStorage, are using origin. The storage interface itself does not, so I do not see any immediate consequences with regards to preferences or any uri scheme discussion. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
