[selectors-api] What's the final call on NSResolver?
We'd like to actually ship a Selectors API implementation in the near future, and since we implement namespaces in CSS we need some resolution on the NSResolver thing. Is it in? Is it out? Are we replacing it with a string instead? Can we ship something sane without NSResolver at all? The discussion seems to have petered out a few weeks ago with no conclusion that I could see. -Boris
[Widgets] Requirements LC
To which Timeless replied... -- Forwarded message -- From: timeless [EMAIL PROTECTED] Date: Thu, Jun 19, 2008 at 7:44 PM Subject: Re: [Widgets] Requirements LC To: Marcos Caceres [EMAIL PROTECTED] (you didn't reply to the list) On 6/18/08, Marcos Caceres [EMAIL PROTECTED] wrote: R35. Configuration Document Data A conforming specification SHOULD specify a means that allows authors to access any relevant data they declared in the configuration *relevant data* document for the widget resource. On Thu, Jun 19, 2008 at 11:20 AM, Marcos Caceres [EMAIL PROTECTED] wrote: If it was irrelevant, it would not have been declared in the config. I don't understand why you think it is irrelevant? your words, not mine. I think you should just delete the word relevant. note that I'm reading everything *very* literally. Yes, that is possible (using XHR to load the config from within the package), but then you have to walk an XML tree which sucks. The other way is to use the properties that we have bound to the Widget object. Check out http://dev.w3.org/2006/waf/widgets-api/Overview.src.html yeah, i'm sure such things are possible in some theoretical sense, but i want to make sure that the API you're asking for doesn't specifically do/enable this.
Re: [Widgets] Requirements LC
On Fri, Jun 20, 2008 at 5:04 PM, Marcos Caceres [EMAIL PROTECTED] wrote: To which Timeless replied... -- Forwarded message -- From: timeless [EMAIL PROTECTED] Date: Thu, Jun 19, 2008 at 7:44 PM Subject: Re: [Widgets] Requirements LC To: Marcos Caceres [EMAIL PROTECTED] (you didn't reply to the list) On 6/18/08, Marcos Caceres [EMAIL PROTECTED] wrote: R35. Configuration Document Data A conforming specification SHOULD specify a means that allows authors to access any relevant data they declared in the configuration *relevant data* document for the widget resource. On Thu, Jun 19, 2008 at 11:20 AM, Marcos Caceres [EMAIL PROTECTED] wrote: If it was irrelevant, it would not have been declared in the config. I don't understand why you think it is irrelevant? your words, not mine. I think you should just delete the word relevant. note that I'm reading everything *very* literally. I removed the word relevant. Yes, that is possible (using XHR to load the config from within the package), but then you have to walk an XML tree which sucks. The other way is to use the properties that we have bound to the Widget object. Check out http://dev.w3.org/2006/waf/widgets-api/Overview.src.html yeah, i'm sure such things are possible in some theoretical sense, but i want to make sure that the API you're asking for doesn't specifically do/enable this. Arve? What does the proposed security policy say about this? Can XHR be used to GET resources inside the package? -- Marcos Caceres http://datadriven.com.au http://standardssuck.org
Re: [Widgets] Requirements LC
On Fri, 20 Jun 2008 09:11:42 +0200, Marcos Caceres [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 5:04 PM, Marcos Caceres [EMAIL PROTECTED] wrote: To which Timeless replied... Yes, that is possible (using XHR to load the config from within the package), but then you have to walk an XML tree which sucks. The other way is to use the properties that we have bound to the Widget object. Check out http://dev.w3.org/2006/waf/widgets-api/Overview.src.html yeah, i'm sure such things are possible in some theoretical sense, but i want to make sure that the API you're asking for doesn't specifically do/enable this. Arve? What does the proposed security policy say about this? Can XHR be used to GET resources inside the package? The security policy proposed by Opera (and mostly implemented already) allows you to XHR any content stored within the package archive itself, just as it would allow you to include the contents of a package through script src, img src et al. This happens through treating a widget: protocol URI where the identifier-portion matches the instance ID of the widget as being same-origin. Thus, allowing XHR is an (intended) side-effect, so you can read other content from the widget (configuration data stored in an XML file or template snippets used throughout the application, for instance), and I don't think a specification will need to mention or reference XHR specifically, except perhaps informatively. -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
[widgets] Device Specific APIs and Services
Hi,
What follows is an *extremely rough* strawman proposal to address
R30. Device Specific APIs and Services, of the widget requirements
document. This proposal is intended for discussion and is deliberately
thin on technical details.
Requirement 30 of the Widgets requirements document is as follows:
A conforming specification should specify a mechanism, either through
an API or through the configuration document, which allows
instantiated widgets to bind to third-party APIs that allow access to
device-specific resources and services. A conforming specification is
not required to specify any APIs to device specific resources or
services, but should provide some means of binding to those APIs if
they are available.
Motivation:
Current development practice or industry best-practices, ease of use.
Rationale:
To endow widgets with functionality beyond what is currently available
to HTML documents, allowing widgets to be used as means to bridge
special device capabilities and operating system services with data on
the Web. Examples of device-specific services and resources that could
be made available through script include cameras, SMS, geolocation and
address book. There are other WGs working on this requirements such
as the Ubiquitous Web Applications Working Group (UWA-WG), and the
Open Mobile Alliance (OMA) Device Capabilities Working Group.
=The Proposal=
There are two aspects to the proposal: a declarative aspect and
programmatic aspect.
Declarative aspect:
The declarative side would involve declaring the intention to use an
API that may or may not be part of the standard set of APIs that
shipped with the widget engine. We declare the intention to use an API
in the configuration document for security purposes (the config.xml
file cannot be written to by the widget engine and the config file can
be digitally signed). APIs are identified as resources via URIs. For
example:
widget
access network=true
requires id=gps
src=http://gps.w3.org/api.jar;
type=application/jar
kind=api /
/access
/widget
The interfaces that bind this binary component to JavaScript would
need to be standardized and I have no idea what they would look like
at this point.
Programatic aspect
At runtime, in we would need something like the following interfaces:
interface APILoader{
attribute APILoader APILoader(DOMString id); // the id declared
void load(); //load the API
void cancel(); //cancel loading
//progress events...
attribute EventListener onLoad;
attribute EventListener onProgress;
attribute EventListener onError;
...etc...
}
interface api{
Object bind(); //binds the api to runtime
enum interfaces(); //returns a list of methods
void unbind(); //removes the binding from memory
}
Example usage:
apiLoader = new APILoader(gps); //must match an id in config.xml
apiLoader.onLoad = function(loadedAPI){
try{
gps = loadedAPI.bind();
loc = gps.getLastLoc();
catch(e){
}
}
apiLoader.onError = function(loader){}
apiLoader.load();
--
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org
Re: [Widgets] Requirements LC
On Fri, Jun 20, 2008 at 11:08 AM, Arve Bersvendsen [EMAIL PROTECTED] wrote: The security policy proposed by Opera (and mostly implemented already) allows you to XHR any content stored within the package archive itself, just as it would allow you to include the contents of a package through script src, img src et al. I guess I've failed to explain myself. (Please keep in mind that this is a comment on the meta requirements spec. I haven't had time to review much else, although I do want to.) As long as the code actively uses XHR (or something else) to retrieve data, I have no objection. What I don't want is something where a property (of the settings object!) is automatically resolved to the result of its pointer location. If a property icon has value http://example.org/favicon.ico;, then i would want retrieval of icon to yield http://example.org/favicon.ico; and not the _data_ that is at the location http://example.org/favicon.ico. I'm perfectly fine with the widget then using an XHR or whatever to retrieve the data for the referenced location. I just don't want a property lookup to resolve an indirection. This happens through treating a widget: protocol URI where the identifier-portion matches the instance ID of the widget as being same-origin. Thus, allowing XHR is an (intended) side-effect, so you can read other content from the widget (configuration data stored in an XML file or template snippets used throughout the application, for instance), and I don't think a specification will need to mention or reference XHR specifically, except perhaps informatively. that's fine.
Re: [Widgets] Requirements LC
On Fri, 20 Jun 2008 12:25:04 +0200, timeless [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 11:08 AM, Arve Bersvendsen [EMAIL PROTECTED] wrote: The security policy proposed by Opera (and mostly implemented already) allows you to XHR any content stored within the package archive itself, just as it would allow you to include the contents of a package through script src, img src et al. I guess I've failed to explain myself. (Please keep in mind that this is a comment on the meta requirements spec. I haven't had time to review much else, although I do want to.) As long as the code actively uses XHR (or something else) to retrieve data, I have no objection. What I don't want is something where a property (of the settings object!) is automatically resolved to the result of its pointer location. If a property icon has value http://example.org/favicon.ico;, then i would want retrieval of icon to yield http://example.org/favicon.ico; and not the _data_ that is at the location http://example.org/favicon.ico. In some way, a specification of, for instance, a widget icon, will reference the icon by URI, not by means of the raw data stored within the image. However, specifically for icons, we might end with some level of indirection to the URL, to accomodate for icon changes that might occur as a result of external actions, such as a user changing his system preference to list large icons instead of small icons. -- Arve Bersvendsen Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] Device Specific APIs and Services
On Fri, Jun 20, 2008 at 11:37 AM, Marcos Caceres
[EMAIL PROTECTED] wrote:
APIs are identified as resources via URIs. For
example:
widget
access network=true
requires id=gps
src=http://gps.w3.org/api.jar;
This worries me. see clsid: and the problems of activex for porting platforms.
(I work on microb, and we're trying to have support for the series 60
browser widgets which have a number of things which I really don't
like and which we can't easily implement.)
type=application/jar
kind=api /
/access
/widget
The interfaces that bind this binary component to JavaScript would
bad. Is api.jar really the binary component?
If what you mean is that api.jar contains an IDL file or something
equivalent to this, then it may be OK, although the language
definitely needs work.
need to be standardized and I have no idea what they would look like
at this point.
interface APILoader{
attribute APILoader APILoader(DOMString id); // the id declared
sorry, i don't recognize this syntax. typically attributes don't take arguments.
void load(); //load the API
void cancel(); //cancel loading
what happens if the load has already finished?
can i unload() ?
gps = loadedAPI.bind();
you declared load() earlier, not bind().
Re: ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All Products]
All, On Jun 17, 2008, at 7:10 PM, ext Charles McCathieNevile wrote: On Wed, 18 Jun 2008 05:45:04 +0900, Web Applications Working Group Issue Tracker [EMAIL PROTECTED] wrote: ISSUE-7 (Transfer Old Issues): Transferring old WebAPI and WAF [All Products] http://www.w3.org/2008/webapps/track/issues/ Raised by: Doug Schepers On product: All Products Should We transfer old issues from WebAPI and WAF to this Tracker? Hmmm. It's a bit of a pain either way. Probably any open issues should be reopened in this tracker, with a pointer placed in the old one... In the next day or two I will copy WAF's Open Issues (only 7) to WebApps' Tracker. -Regards, Art Barstow
Re: Opting in to cookies - proposal version 3
Ian Hickson wrote: On Thu, 19 Jun 2008, Jonas Sicking wrote: That is, your solution only works so long as the site doesn't ever opt in to cookies. Which seems uncommon. This is not true. You can opt in to cookies on just a subset of the URIs where you opt in to Access-Control with my proposal. But the _entire assumption_ here is that the author is unable to correctly apply these features to the right subset of his site. If the author was able to correctly apply these features to the appropriate subset, then we wouldn't need your feature in the first place. No, that is not the assumption. I'll try to rephrase. In the example below i'll use PHP as the server side technology for: My concern is for a site operator which understands the spec and wants to share public data being offered from all or part of the URI space for the site. Under the current spec the operator must check each individual PHP script in the part of the site that is shared to make sure that none of them use $_SESSION, $_COOKIE, $HTTP_SESSION_VARS, $_ENV['HTTP_COOKIE'], HttpRequest::getCookies(), any of the session_* functions, $_ENV['REMOTE_USER'], $_ENV['REMOTE_IDENT'], $_ENV['HTTP_AUTHORIZATION'] any of the kadm5_* functions, any of the radius_* functions or anything else that I'm missing that does session management based on user credentials. If any of these things are used then the PHP script is likely mixing private data into the public data and so the script needs to be modified to not use any of the above features when the 'Origin' header is present and has a value different from the current domain. While this is certainly doable, I feel that there is a risk that the site administrator will make a mistake and miss some of the above listed features and cause private data to be leaked. So again, the issue isn't in understanding the spec. The issue is securing your site for the security model that the spec requires. Additionally, this way you can make sure to ask the user always before sending the Access-Control-With-Credentials header. This way the risk of leaking private data without the user realizing is further reduced. But we both know browsers aren't going to do this, or will offer a never ask me again checkbox. I'm talking about the site asking the user this question. The site should always check with the user before sharing any of the users private data with any third party. If we separate out opting in to cookies from opting in to Access-Control then sites can easier ensure that any time they opt in to cookies, they only do so after having asked the user. (I'm assuming that the case of providing data cross-domain for simple GET requests is most easily handled just by having that script send back the right magic, in which case none of this applies as the URI space is one URI and there are no preflights at all. For this use case we don't have to worry about cookies at all as the server just wouldn't look at them.) I'm not following what you are saying here. What script is that script? And what is the right magic? The script that provides the data, and the right magic is the Access-Control header. I'm sorry, i'm totally at a loss about what you are saying here, I suspect I'm missing some context. Could explain from the beginning? / Jonas
Re: IRC logging
Can anyone really ever mention things that are member confidential on IRC? We have no control over who else is in the room and possibly logging. / Jonas Charles McCathieNevile wrote: Hi Anne, this raises a couple of issues - the obvious one being how we deal with meetings which include information that is member-only, and also whether the logger has some facility for saying something that doesn't go into the record, as the W3C log bots do. Hopefully we will clear this up in the next couple of days - the chairs have been discussing this and agree that we want it to happen, but want to sort the issues. I'll follow up in private - with luck we can resolve this all by Monday, but please ask Krijn not to run a logger until we have sorted this out. cheers Chaals On Wed, 18 Jun 2008 12:27:55 +0300, Anne van Kesteren [EMAIL PROTECTED] wrote: Hi, Krijn Hoetmer volunteered for logging our IRC channel (#webapps on irc.w3.org:80) similarly to how he logs for the HTML WG, CSS WG, and WHATWG. (Also the public ARIA discussion channel I believe.) If you have any objections to this please say so before the weekend. If people find it more appropriate to decide this using a survey that would be fine with me as well, but since I don't expect opposition that seems like quite a bit of overhead. Kind regards,
RE: XHR2 Feedback As Tracker Issues (was: [NOT] Microsoft's feedback on XHR2)
As a general rule, I'm in favor of that - or at least some way of forking the discussions and only requiring individuals to be involved in what they're interested/expert in. -Original Message- From: Marcos Caceres [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2008 4:06 PM To: Sunava Dutta Cc: Arthur Barstow; ext Doug Schepers; Chris Wilson; Ian Hickson; Marc Silbey; public-webapps; Eric Lawrence; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu; Michael Champion Subject: Re: XHR2 Feedback As Tracker Issues (was: [NOT] Microsoft's feedback on XHR2) On Fri, Jun 20, 2008 at 7:30 AM, Sunava Dutta [EMAIL PROTECTED] wrote: Here's how I feel we would benefit. At MSFT we've got lots of experts across the company, however I cant really have them join the aliases as in many cases a vast majority of the discussions are not relevant to them and in many cases not even in their current commitments (for example let's say the original designers of IE's XHR who are currently working on a new project). Nonetheless, their expertise is really valuable occasionally. Also, if people who are involved are out sick and/or vacation, they need to plough trough lots of difficult to follow plain text emails or clips of comments (that don't have a thread compression or hierarchy) to get up to speed. In this case it's really hard for the program manager (myself) to proxy all relevant conversations from the archives to these entities by saving the emails as attachments, highlighting relevant areas or sending links to a dispersed set of emails on the archives tracking the issues and discussions. I've been trying to assimilate the info and conversations on relevant issues and distil them to the internal parties, however it doesn't scale well. What would be helpful I feel would be to have the tracker with all relevant discussions and latest status included. This would let me send a link of the relevant issue to the parties internally. Thoughts are welcome. Personally, I would prefer specific mailing lists or rss feeds for each spec the WG is working on. -- Marcos Caceres http://datadriven.com.au http://standardssuck.org
RE: New: Tracking Issues in XHR that we raisedRE: Was: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Thanks. I think we will consider the tracker for future threads and also use the F2F. Meanwhile, Zhenbin has answered Jonas. -Original Message- From: Doug Schepers [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2008 8:57 PM To: Sunava Dutta Cc: Jonas Sicking; Zhenbin Xu; Ian Hickson; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: New: Tracking Issues in XHR that we raisedRE: Was: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite Hi, Sunava- Sunava Dutta wrote (on 6/19/08 10:47 PM): -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] I do agree we have debate, I don't agree we have agreement on that throwing an exception is the right thing to do. The argument for returning null is that it makes for a cleaner API, exceptions should only be thrown in exceptional circumstances. And based on available data it doesn't seem like sites currently care one way or another, so I think we should go for the cleaner API. What is the argument for throwing an exception? [Sunava Dutta] I can't believe you asked that question after all the discussions that just happened on that with Ian, Zhenbin and you. With all due respect, is this an 'engage and lock' until someone gets frustrated and quits strategy or is there something outside of technical arguments that Mozilla is concerned about? -:) I don't think that's a productive or adequate reply to what is a simple question (and it doesn't help the tone here). Jonas (who is, in my experience, a problem-solver, not a drama diva) has clearly stated the position for returning null (regardless of the merits of that position). The most straightforward reply would be to simply state (or restate, if it's been stated) the counter-argument, and for the WG to meet to decide on it, via telcon or F2F. Email is not the best place for persistent atomic pros and cons, so I suggest that you either outline the opposing arguments in Tracker, or on the wiki: http://www.w3.org/2008/webapps/wiki/XHR That way we can look at the arguments dispassionately, side by side, and decide on the merits. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Re: Opting in to cookies - proposal version 3
Ian Hickson wrote: On Fri, 20 Jun 2008, Jonas Sicking wrote: Under the current spec the operator must check each individual PHP script in the part of the site that is shared to make sure that none of them use $_SESSION, $_COOKIE, $HTTP_SESSION_VARS, $_ENV['HTTP_COOKIE'], HttpRequest::getCookies(), any of the session_* functions, $_ENV['REMOTE_USER'], $_ENV['REMOTE_IDENT'], $_ENV['HTTP_AUTHORIZATION'] any of the kadm5_* functions, any of the radius_* functions or anything else that I'm missing that does session management based on user credentials. If any of these things are used then the PHP script is likely mixing private data into the public data and so the script needs to be modified to not use any of the above features when the 'Origin' header is present and has a value different from the current domain. While this is certainly doable, I feel that there is a risk that the site administrator will make a mistake and miss some of the above listed features and cause private data to be leaked. So again, the issue isn't in understanding the spec. The issue is securing your site for the security model that the spec requires. That's all well and good, but what if the site author wants to send back some data that _is_ cookie aware? Now he has to go through and do the check anyway. So what's the win? I think it's safe to assume that if the site uses cookies at all, that it'll eventually want to provide cross-site access to user data in some way. Ah, sorry, I think I missed your point here. I don't think that is unnecessarily true at all. I think one sticking point is that I suspect sites will opt in to Access-Control on pages they are already serving to their users. So I would not be surprised if yahoo opts in on the uri news.yahoo.com URI, or craigslist opt in for their full URI space. In such cases I think it's very possible that sites will opt in on URIs that receive and process cookies, but would leak private data if they did so with cookies enabled. / Jonas
