Re: [webidl] [Implements] extended attribute
On Mon, 09 Feb 2009 20:43:56 +0100, Ian Hickson i...@hixie.ch wrote: (Incidentally, since XMLHttpRequestEventTarget inherits from EventTarget, XMLHttpRequestUpload should implement the former only.) I was thinking of maybe breaking that though in case of XMLHttpRequestEventTarget I suppose it makes actual sense to use inheritance. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[cors] ACTION-11 API use cases
I took a stab at ACTION-11 which is currently assigned to Maciej: http://www.w3.org/2008/webapps/track/actions/11 http://dev.w3.org/2006/waf/access-control/#use-cases If this is good enough I suggest we close the action. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [cors] ACTION-11 API use cases
I don't think the presented XBL use case is valid: An XBL binding allows full access to the document it is bound to and therefore cross-origin XBL usage is prohibited. The resource sharing policy enables cross-origin XBL bindings. If the user is authenticated with the server that hosts the XBL widget it is possible to have a user-specific cross-origin bindings. I'm not sure whether an XBL binding allows full access to the document it is bound to is talking about accessing the DOM of the bound-document or the binding-document, but I don't think either case requires access-control. I don't see where the XBL spec says that the bound-document must have access to the binding-document, so I don't understand why cross-origin restrictions would apply. And I don't understand why we should prohibit the XBL binding having access to the bound-document. That's the whole point of XBL, and we already have the same situation with script src. If you don't trust the XBL bindings then don't reference them, just like with scripts. Anne van Kesteren wrote: I took a stab at ACTION-11 which is currently assigned to Maciej: http://www.w3.org/2008/webapps/track/actions/11 http://dev.w3.org/2006/waf/access-control/#use-cases If this is good enough I suggest we close the action.
Re: [cors] ACTION-11 API use cases
On Tue, 10 Feb 2009 13:00:35 +0100, Sean Hogan shogu...@westnet.com.au wrote: I don't think the presented XBL use case is valid: An XBL binding allows full access to the document it is bound to and therefore cross-origin XBL usage is prohibited. The resource sharing policy enables cross-origin XBL bindings. If the user is authenticated with the server that hosts the XBL widget it is possible to have a user-specific cross-origin bindings. I'm not sure whether an XBL binding allows full access to the document it is bound to is talking about accessing the DOM of the bound-document or the binding-document, but I don't think either case requires access-control. I don't see where the XBL spec says that the bound-document must have access to the binding-document, so I don't understand why cross-origin restrictions would apply. And I don't understand why we should prohibit the XBL binding having access to the bound-document. That's the whole point of XBL, and we already have the same situation with script src. If you don't trust the XBL bindings then don't reference them, just like with scripts. That example is based on http://www.w3.org/TR/2007/CR-xbl-20070316/#security and maybe some discussion with Ian regarding this. It's been a while. Does that help? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [widgets] Comments on the 22-Dec-2008 LCWD of the Widgets 1.0: PC spec
Marcos, On Feb 3, 2009, at 9:15 AM, ext Marcos Caceres wrote: The spec now reads: [[ A user agent is a user agent that attempts to implement this specification. Note: The user agent described in this specification does not denote a widget user agent at large: that is, a user agent that implements all the specifications, and dependencies, defined in the Widgets 1.0: Family of Specifications. The user agent described is this specification is only concered with how to processes zip archives and configuration documents. ]] I would change is that is, a user agent to that is, a widget user agent. Understood. Can you please check that sections 3.0, 3.1, 3.2, 3.3 are all OK? Re 3.2, 2nd paragraph - one change I suggest is to add a reference to ITS specification e.g. ITS specification [SOME_REF]. Otherwise, looks OK to me. -Regards, Art Barstow
Re: Seeking implementation status of XBL2
On Feb 10, 2009, at 00:39 , Sean Hogan wrote: There are a few active JS implementation projects: I don't know if there is precedent in counting JS-based implementations as valid implementation to get a spec out the door (maybe the Forms WG did it?) but I see no reason not to. In fact, I could make the argument that they should count *more* as they allow technology to be deployed faster than the browser churn. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Seeking implementation status of XBL2
We're interested in implementing XBL2 in WebKit as well, though I can't give a specific timetable. On Feb 10, 2009, at 6:39 AM, Robin Berjon wrote: On Feb 10, 2009, at 15:27 , Boris Zbarsky wrote: Robin Berjon wrote: I don't know if there is precedent in counting JS-based implementations as valid implementation to get a spec out the door (maybe the Forms WG did it?) but I see no reason not to. In fact, I could make the argument that they should count *more* as they allow technology to be deployed faster than the browser churn. Assuming the JS-based implementations actually implement the spec as written, yes. But since the point of the implementation requirement is to make sure that the spec is in fact implementable, implementations that don't _quite_ implement it shouldn't count towards the two interoperable implementations criterion. Oh, I fully agree with that, the point is not to water down the interoperability requirements. I simply want to make sure that JS- based implementations are counted as real as there often is a misperception that they are somehow just hacks. Sure, JS-based implementations should count as real if they in fact fully implement the spec. However, native browser-hosted implementations may well run into issues that may not affect a JS- based implementation, and our endgame goal here is to have interoperable browser-native implementations. So overall, I think it would be unwise to advance the spec to PR on the strength of JS-based implementations alone. Regards, Maciej
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
On Wed, Feb 4, 2009 at 1:26 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: This is a pretty radical change; I can certainly see the logic of it in terms of reducing spec overlap. However, it does presume that semantically a widget preference is the same as client-side storage. In our implementation, storage is definitely server-side, so this mechanism would not really work for us. I'm not sure I understand the difference. Can you describe why your implementation wouldn't be able to store the HTML5 API server-side? Are there any changes we could do to the HTML5 API that would allow a server-side back-end? / Jonas
Re: [cors] ACTION-11 API use cases
Anne van Kesteren wrote: On Tue, 10 Feb 2009 13:00:35 +0100, Sean Hogan shogu...@westnet.com.au wrote: I don't think the presented XBL use case is valid: An XBL binding allows full access to the document it is bound to and therefore cross-origin XBL usage is prohibited. The resource sharing policy enables cross-origin XBL bindings. If the user is authenticated with the server that hosts the XBL widget it is possible to have a user-specific cross-origin bindings. I'm not sure whether an XBL binding allows full access to the document it is bound to is talking about accessing the DOM of the bound-document or the binding-document, but I don't think either case requires access-control. I don't see where the XBL spec says that the bound-document must have access to the binding-document, so I don't understand why cross-origin restrictions would apply. And I don't understand why we should prohibit the XBL binding having access to the bound-document. That's the whole point of XBL, and we already have the same situation with script src. If you don't trust the XBL bindings then don't reference them, just like with scripts. That example is based on http://www.w3.org/TR/2007/CR-xbl-20070316/#security and maybe some discussion with Ian regarding this. It's been a while. Does that help? Ok, I can see that the use case is consistent with what is in the XBL spec. I prefer the following wording: A XBL binding allows the document to which it is bound to have full access to the document in which it is defined; therefore cross-origin XBL usage is prohibited. I disagree with the security context of a XBL document being the bound document, but that isn't relevant to this thread.
