Re: Length of LC comment period
Maciej Stachowiak wrote: On Dec 8, 2009, at 6:09 AM, Ian Hickson wrote: On Tue, 8 Dec 2009, Marcos Caceres wrote: Cheer up, I can think of _much_ worst things that have popped out of the W3C onto the Web than Web Storage:) Yeah but they typically have minimal impact on the deployed Web, unlike the storage mutex problem. So hang on... Why are going to LC if this is such a massive issue? Well from the point of view of the spec, the issue is resolved. It just has unfortunate performance implications for multi-process UAs. It seems pretty clear that multi-process UAs are refusing to implement the requirement. It also seems likely that more UAs will go multiprocess over time. Thus, it may not be possible to exit CR with this requirement. For this case, I don't see why the spec can't just describe the expected behavior and leave it to implementations to figure out how to solve the issue. It seems like being algorithmically over prescriptive here will lock people into certain architectures. If the prescribed behavior proves to be impossible to implement during CR, then we can drop back to LC and write the algorithm to solve this in prose. Kind regards, Marcos
Re: Semi-public resources in Uniform Messaging
On Tue, 08 Dec 2009 20:56:33 +0100, Tyler Close tyler.cl...@gmail.com wrote: I assume you want to move on to the XHR-like example, so I've just got a few clarification questions about it... The other examples are important too. If the idea is to replace CORS with UM it at least has to address the same use case scenarios, imo. -- Anne van Kesteren http://annevankesteren.nl/
Re: Semi-public resources in Uniform Messaging
On Tue, 8 Dec 2009, Tyler Close wrote: I assume you want to move on to the XHR-like example, so I've just got a few clarification questions about it... The examples are equivalent as far as I can tell. Both are important; for me, the video one is more important since I'm editing the spec that will need to define how to work with video. On Tue, Dec 8, 2009 at 11:18 AM, Ian Hickson i...@hixie.ch wrote: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0914/draft.html To recast the question in terms of XMLHttpRequest, how would one label a static resource on an intranet server, e.g.: http://marketing.corp.example.com/productcodes.xml ...such that it can be read (using XMLHttpRequest) by scripts embedded on pages from the following hosts: http://www.corp.example.com/ http://finance.corp.example.com/ http://eng.corp.example.com/ http://intranet.example.com/ ...but such that it could _not_ be read by pages from the following hosts (i.e. the HTTP response would not be made accessible to scripts on pages from these hosts): http://hostile-blog.example.com/ http://www.hostile.example/ Are you saying a firewall prevents the author of the attack pages from directing his own browser to any of the legitimate pages that have access to the data? I don't think the firewall situation is really relevant, but for the sake of argument, let's say that the user is inside the fireall (or on VPN), and that *.corp.example.com are only accessible inside the firewall, and that intranet.example.com is accessible outside but only through TLS and with strong client authentication, and that hostile-blog.example.com and www.hostile.example are accessible outside without authentication. So, all the resources with access to the secret data are hosted by servers behind a firewall; and all the attackers are outside the firewall? No. Furthermore, all the resources with access to the secret data are trusted to not send the secret data to the attacker? Yes, the resources who should be able to read the secret data are trusted not to send the data to untrusted third parties. It also seems that any resource hosted behind the firewall also has access to the secret data, since it can just send a request server-to-server, instead of server-to-browser-to-server. True? In this example, yes, the resource on marketing.corp.example.com is not protected from direct access in any way other than via the firewall. A more realistic example would probably have the resource protected from direct access by cookie-based authentication, but for the time being I think it's simpler to focus on the example without _user_ authentication being present also. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Length of LC comment period
On Wed, 9 Dec 2009, Marcos Caceres wrote: It seems pretty clear that multi-process UAs are refusing to implement the requirement. It also seems likely that more UAs will go multiprocess over time. Thus, it may not be possible to exit CR with this requirement. For this case, I don't see why the spec can't just describe the expected behavior and leave it to implementations to figure out how to solve the issue. It seems like being algorithmically over prescriptive here will lock people into certain architectures. If the prescribed behavior proves to be impossible to implement during CR, then we can drop back to LC and write the algorithm to solve this in prose. That's what the spec does. The expected behaviour can't be implemented without the performance problem for multiprocess browsers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: call for reviewers: XMLHttpRequest Last Call
Documentation: http://ha.ckers.org/blog/20070712/user-agent-spoofable-using-certain-programming-languages/ Greetings!! -- Eduardo http://www.sirdarckcat.net/ Sent from Hangzhou, 33, China On Wed, Dec 9, 2009 at 6:29 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 08 Dec 2009 11:46:43 +0100, s...@rckc.at s...@rckc.at wrote: @Anne, what about the - alias for _ on Apache on request headers? It would be good to have some more documentation on that particular issue. (In general I'm planning on addressing XHR feedback after December 15. Also, feedback is ideally mailed towards public-weba...@w3.org. That is the group responsible for the document.) -- Anne van Kesteren http://annevankesteren.nl/
Re: call for reviewers: XMLHttpRequest Last Call
oops I meant http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.html -- Eduardo http://www.sirdarckcat.net/ Sent from Hangzhou, 33, China On Wed, Dec 9, 2009 at 6:31 PM, s...@rckc.at s...@rckc.at wrote: Documentation: http://ha.ckers.org/blog/20070712/user-agent-spoofable-using-certain-programming-languages/ Greetings!! -- Eduardo http://www.sirdarckcat.net/ Sent from Hangzhou, 33, China On Wed, Dec 9, 2009 at 6:29 PM, Anne van Kesteren ann...@opera.comwrote: On Tue, 08 Dec 2009 11:46:43 +0100, s...@rckc.at s...@rckc.at wrote: @Anne, what about the - alias for _ on Apache on request headers? It would be good to have some more documentation on that particular issue. (In general I'm planning on addressing XHR feedback after December 15. Also, feedback is ideally mailed towards public-weba...@w3.org. That is the group responsible for the document.) -- Anne van Kesteren http://annevankesteren.nl/
RE: [EventSource] Comments to the current draft
On Mon, 7 Dec 2009, SULLIVAN, BRYAN L (ATTCINW) wrote: I suggest to change This can result in considerable power savings. to This can result in considerable resource savings, e.g. power and data usage. I've added a mention of data usage savings, though I've avoided the use of the word resources since that term really is way too overloaded already. I suggest we add an informative reference: [OMAPush] OMA Push, Open Mobile Alliance. June 2009. The HREF on OMA Push should be http://www.openmobilealliance.org/Technical/current_releases.aspx. June 2009 is the latest release of the Push enabler. I started adding this reference, but in attempting to double-check the URI, I found that it is impossible to read the document without agreeing to a license, so I couldn't finish checking the reference. Is there a URL that is to the actual spec rather than to a list of specs? Ian wrote: On Tue, 27 Oct 2009, SULLIVAN, BRYAN L (ATTCINW) wrote: Re HTTP 200 OK responses that have a Content-Type other than text/event-stream (or some other supported type): other supported type I suppose means some arbitrary MIME type supported by the user agent. Are there any practical limitations on what MIME types can be supported? Well, they have to be formats that are relevant; I mean, image/png wouldn't make much sense. Beyond that, I don't believe so. Thanks. I'm guessing relevance means to the web application, and not just that natively supported by the user agent. The context here is what formats are allowed to be supported by user agents. By relevant, I mean the formats have to be something that could theoretically be supported in a way that fits the API -- it has to be something that encodes discrete events, for instance. What makes sense is still a key question to me - I'm not sure exactly why an image file (encoded) would not make sense [...] No specification defines how you turn an image/png file into a set of events, so I don't understand what it would mean for a user agent to support image/png as an event source format. Unique domain names per connection is unclear and does sound complex and non-scalable. It's not that complex, it just requires wildcarding in the DNS. How should I clarify this? Thanks. No change needed, I guess those familiar with the server implementation will understand it. Since I'm not familiar with this specific technique, is it intended that the client can use a random sub-domain (e.g. e8d7yewd7yc.myserver.com) which is mapped to myserver.com since the DNS record is *.myserver.com? The idea is that instead of just talking to www.example.com, you would talk to www1.example.com and www2.example.com and so on. How exactly this maps to DNS records is not my area of expertise. Allowing the user to enable... is also likely an experience-killer. Indeed, it's not ideal. It's an option, though. Thanks. Is there a specific way that the browser can detect a per-server connection limitation? If so, it (or the webapp, if there is an error event that discloses the condition) could react more gracefully (e.g. back off on the number of simultaneous connections, or allow the user to turn off/down the eventsource use for that domain). The browser is the one that enforces the per-server connection limitation (per the HTTP spec). I agree that we should consider exposing this to the Web app, but I think we should do that in a future version, once we know how much of a problem this is. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[widgets] PC simplifying some rules (editorial)
Hi all, I noticed that 9.1.3. Rule for Finding a File Within a Widget Package indicates that the algorithm returns either a file, null, or an error.. This is not exactly true since if it does return an error or null, it always returns a processable file. I suggest changing the introduction as follows The algorithm returns either a processable file, null, or an error. and then doing the following three edits: - Change point 7 in the license element in 9.1.15. Algorithm to Process a Configuration Document to indicate: If file is null or there is an error in 6 then ignore this element - Change the similar point for the icon element. - Simplify Step 9 - Process the Default Icons by collapsing A.A, A.B and A.C into if potential icon is null or in error or already exists, ignore it Also, I was wondering for quite some time why the spec has a strange structure for Rules vs. Steps. Couldn't you put all the Rules into one section 9.1 and all the Steps in 9.2? Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] test-cases for icons: some possible errors
Scott Wilson a écrit : On 3 Dec 2009, at 17:26, Marcos Caceres wrote: On Sun, Nov 29, 2009 at 6:03 PM, Scott Wilson scott.bradley.wil...@gmail.com mailto:scott.bradley.wil...@gmail.com wrote: Some more potential test case errors and fixes: == bl.wgt ✔ Tests the UA's ability to locate an icon in a locale folder and at the root of the widget. To pass, after processing, the icons list must contain a pointer to locales/en/icon.jpg, and icon.png, which is at the root of the widget. The icons list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Following Step 9 and using Rule for Finding a File Within a Widget Package I always get these the other way around, as icon.png is in front of icon.jpg in the default icons list mmm. I'm not sure I understand how that happens? Section 9.1.3. Rule for Finding a File Within a Widget Package, step 5 in the algorithm should be forcing you to find the localized icon first. Please recheck the spec and I can try to clarify where it is confusing in regards to how files are found (i.e., always localized content first, then followed by unlocalized content) Step 9 is as follows: *For* each file name in the default icons table http://dev.w3.org/2006/waf/widgets/#default-icons-table (from top to bottom) that has a media type http://dev.w3.org/2006/waf/widgets/#media-type0 that is supported http://dev.w3.org/2006/waf/widgets/#supported by the user agent: 1. Let potential-icon be the result of applying the rule for finding a file within a widget package http://dev.w3.org/2006/waf/widgets/#rule-for-finding-a-file-within-a-widget-0 to file name. 2. If the following conditions are all |true|, then append the value of potential-icon to the icons http://dev.w3.org/2006/waf/widgets/#icons0 list of the table of configuration defaults http://dev.w3.org/2006/waf/widgets/#table-of-configuration-defaults: 1. The value of potential-icon is a file http://dev.w3.org/2006/waf/widgets/#file. 2. The potential-icon is a processable file http://dev.w3.org/2006/waf/widgets/#processable-file, determined by the media type http://dev.w3.org/2006/waf/widgets/#media-type0 given in the media type column of the default icons table http://dev.w3.org/2006/waf/widgets/#default-icons-table. 3. The potential-icon does not already exist in the icons http://dev.w3.org/2006/waf/widgets/#icons0 list of the table of configuration defaults http://dev.w3.org/2006/waf/widgets/#table-of-configuration-defaults. 3. Move onto the next file name in the default icons table http://dev.w3.org/2006/waf/widgets/#default-icons-table. So, using this algorithm, pass.png would always come before locales/en/pass.jpg E.g For (icon in icon.svg, icon.ico, icon.png, icon.gif, icon.jpg): A: Looked for icon.svg using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.ico using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.png using the rule in 9.1.3. No localized version, so got root icon.png. B: Appended /icon.png C: Next! A: Looked for icon.gif using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.jpg using the rule in 9.1.3. Found locales/en/icon.jpg B: Appended locales/en/icon.jpg C: Done! Icons List = icon.png, locales/en/icon.jpg I agree. The whole point here is that Step 9 applies on top of Step 5. Step 5 handles the priority of a localized resource over non localized resource sith the same name. This is not the case here. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: Length of LC comment period
Ian Hickson wrote: On Wed, 9 Dec 2009, Marcos Caceres wrote: It seems pretty clear that multi-process UAs are refusing to implement the requirement. It also seems likely that more UAs will go multiprocess over time. Thus, it may not be possible to exit CR with this requirement. For this case, I don't see why the spec can't just describe the expected behavior and leave it to implementations to figure out how to solve the issue. It seems like being algorithmically over prescriptive here will lock people into certain architectures. If the prescribed behavior proves to be impossible to implement during CR, then we can drop back to LC and write the algorithm to solve this in prose. That's what the spec does. The expected behaviour can't be implemented without the performance problem for multiprocess browsers. Ok, I'll see if I can pump out a test suite over the next month or two. Let me know if you have a preferred format or conventions that you would want me to use. Marcos
Re: Length of LC comment period
On Wed, 9 Dec 2009, Marcos Caceres wrote: Ok, I'll see if I can pump out a test suite over the next month or two. Let me know if you have a preferred format or conventions that you would want me to use. Cool, thanks. I don't have any personal preferences here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [widgets] test-cases for icons: some possible errors
Hi all, Scott Wilson a écrit : Some more potential test case errors and fixes: == bl.wgt ✔ Tests the UA's ability to locate an icon in a locale folder and at the root of the widget. To pass, after processing, the icons list must contain a pointer to locales/en/icon.jpg, and icon.png, which is at the root of the widget. The icons list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Following Step 9 and using Rule for Finding a File Within a Widget Package I always get these the other way around, as icon.png is in front of icon.jpg in the default icons list I agree, see my previous mail. == bm.wgt ✔ Tests the UA's ability to deal with custom icon declaration in the config document and matching default icons. To pass, the icons list must contain a pointer to locales/en/icon.jpg and icon.png, which is at the root of the widget. The list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Following Step 9 and using Rule for Finding a File Within a Widget Package I always get these the other way around, as icon.png is in front of icon.jpg in the default icons list I agree but for a different reasons. The reason here is that icon.png is added as a result of Step 7 Process the Configuration Document whereas locales/en/icon.jpg is added as a result of Step 9 Process the Default Icons. Since Step 9 happens after Step 7, the JPG icon happens after the PNG. Actually, I have a problem with the way the test suite result are expressed. Since there is no normative algorithm for the selection of the actual displayed icon, why should the test suite results but so strict. In particular, why does an implementation need to list all icons, if its policy is to select the first one, correct according to the spec, and that matches its needs. For example, one could say: To pass, the icons list must contain a pointer to either locales/en/icon.jpg or icon.png, which is at the root of the widget. If both are listed, the list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
[widgets] Draft Agenda for 10 December 2009 Voice Conf
Below is the draft agenda for the 10 December Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2009/12/03-wam-minutes.html -Regards, Art Barstow Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/ member-bin/irc/irc.cgi Confidentiality of minutes: Public Agenda: 1. Review and tweak agenda 2. Announcements a. No call on Dec 24 or Dec 31 3. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. Review LC disposition of comments document: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- apis-20091117/doc/ b. Normative dependencies in progress: HTML5, Web IDL, Web Storage c. Call for Consensus to publish Candidate Recommendation 4. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Besides DAP WG, are there any other WGs or external groups we want to ask for comments re 8-Dec-2009 LCWD? 5. URI Scheme spec http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ a. Review LC comments: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- uri-20091008/doc/ b. Preparing for Candidate: see 3-Dec-2009 discussion: http://www.w3.org/2009/12/03-wam-minutes.html#item06 6. AOB
Re: [widgets] test-cases for icons: some possible errors
On Dec 9, 2009, at 14:31 , Cyril Concolato wrote: Actually, I have a problem with the way the test suite result are expressed. Since there is no normative algorithm for the selection of the actual displayed icon, why should the test suite results but so strict. In particular, why does an implementation need to list all icons, if its policy is to select the first one, correct according to the spec, and that matches its needs. For example, one could say: Agreed, I think we should test for what the *first* icon is in the list (the one that's selected). Listing all the others isn't useful, they're never used. -- Robin Berjon - http://berjon.com/
Re: [widgets] test-cases for icons: some possible errors
On 9 Dec 2009, at 13:46, Robin Berjon wrote: On Dec 9, 2009, at 14:31 , Cyril Concolato wrote: Actually, I have a problem with the way the test suite result are expressed. Since there is no normative algorithm for the selection of the actual displayed icon, why should the test suite results but so strict. In particular, why does an implementation need to list all icons, if its policy is to select the first one, correct according to the spec, and that matches its needs. For example, one could say: Agreed, I think we should test for what the *first* icon is in the list (the one that's selected). Listing all the others isn't useful, they're never used. In our case we do want to process and store all valid icons for a widget package, as we can display instances of the widget for multiple users, each with different preferred locales. In which case we need to have an appropriate list of widgets that we can select from. However its not quite so clear why we need them stored in a particular order, as we'd query them for the best match to the user's preferences. -- Robin Berjon - http://berjon.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] test-cases for icons: some possible errors
Robin, Robin Berjon a écrit : On Dec 9, 2009, at 14:31 , Cyril Concolato wrote: Actually, I have a problem with the way the test suite result are expressed. Since there is no normative algorithm for the selection of the actual displayed icon, why should the test suite results but so strict. In particular, why does an implementation need to list all icons, if its policy is to select the first one, correct according to the spec, and that matches its needs. For example, one could say: Agreed, I think we should test for what the *first* icon is in the list (the one that's selected). Listing all the others isn't useful, they're never used. I'm not sure the first one is always selected. The order is implied by the default icons table but a UA may decide that it prefers PNG over SVG (e.g. for processing requirements) even if it supports both. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: Semi-public resources in Uniform Messaging
On Wed, Dec 9, 2009 at 1:39 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 8 Dec 2009, Tyler Close wrote: I assume you want to move on to the XHR-like example, so I've just got a few clarification questions about it... The examples are equivalent as far as I can tell. Both are important; for me, the video one is more important since I'm editing the spec that will need to define how to work with video. Since the examples are equivalent, I'll stick to the XHR one for now, since I'm not sure I fully understand the video one yet. On Tue, Dec 8, 2009 at 11:18 AM, Ian Hickson i...@hixie.ch wrote: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0914/draft.html To recast the question in terms of XMLHttpRequest, how would one label a static resource on an intranet server, e.g.: http://marketing.corp.example.com/productcodes.xml ...such that it can be read (using XMLHttpRequest) by scripts embedded on pages from the following hosts: http://www.corp.example.com/ http://finance.corp.example.com/ http://eng.corp.example.com/ http://intranet.example.com/ ...but such that it could _not_ be read by pages from the following hosts (i.e. the HTTP response would not be made accessible to scripts on pages from these hosts): http://hostile-blog.example.com/ http://www.hostile.example/ Are you saying a firewall prevents the author of the attack pages from directing his own browser to any of the legitimate pages that have access to the data? I don't think the firewall situation is really relevant, but for the sake of argument, let's say that the user is inside the fireall (or on VPN), and that *.corp.example.com are only accessible inside the firewall, and that intranet.example.com is accessible outside but only through TLS and with strong client authentication, and that hostile-blog.example.com and www.hostile.example are accessible outside without authentication. The firewall situation determines whether or not an attacker can access the secret data directly, rather than via an attack page. I see that for intranet.example.com, you've replaced the firewall with TLS and strong client authentication. That should serve the same purpose, if we assume that no attackers have an account on intranet.example.com. So, all the resources with access to the secret data are hosted by servers behind a firewall; and all the attackers are outside the firewall? No. I assume that's a no to the first clause only, since an attacker behind the firewall has direct access to the secret data. As discussed in the previous paragraph, you've added TLS and client authentication to intranet.example.com, so that it can live outside the firewall. Furthermore, all the resources with access to the secret data are trusted to not send the secret data to the attacker? Yes, the resources who should be able to read the secret data are trusted not to send the data to untrusted third parties. It also seems that any resource hosted behind the firewall also has access to the secret data, since it can just send a request server-to-server, instead of server-to-browser-to-server. True? In this example, yes, the resource on marketing.corp.example.com is not protected from direct access in any way other than via the firewall. OK, so the whitelist of four sites with access to the data also implicitly includes all sites behind the firewall. A more realistic example would probably have the resource protected from direct access by cookie-based authentication, but for the time being I think it's simpler to focus on the example without _user_ authentication being present also. Ok, then for this initial simpler case, the simplest UMP solution that satisfies the stated security constraints is for marketing to put the product codes at a URL like: https://marketing.corp.example.com/productcodes/?s=42tjiyrvnbpoal , where the value of the s query string parameter is an unguessable secret. A GET response from this URL is served with the same-origin opt-out header. The product code URL is then given to all sites that should have access to the data. The data display page at these sites starts by getting a copy of the product code URL. The HTTP response that returns the product code URL must either be protected by some access-control mechanism, or not include the same-origin opt-out header. The data display page can then use an UMP XHR to access the product code data using the product code URL. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: Semi-public resources in Uniform Messaging
On Wed, 9 Dec 2009, Tyler Close wrote: Ok, then for this initial simpler case, the simplest UMP solution that satisfies the stated security constraints is for marketing to put the product codes at a URL like: https://marketing.corp.example.com/productcodes/?s=42tjiyrvnbpoal , where the value of the s query string parameter is an unguessable secret. A GET response from this URL is served with the same-origin opt-out header. Renaming files to have unguessable names seems counter to best practice regarding URI naming. Ok, let's move on to a more complex case. Consider a static resource that is protected by a cookie authentication mechanism. For example, a per-user static feed updated daily on some server by some automated process. The server is accessible on the public Web. The administrator of this service has agreements with numerous trusted sites, let's say a dozen sites, which are allowed to fetch this file using XHR (assuming the user is already logged in). The sites that fetch this file do not require authentication (e.g. one could be my portal page, which is just a static HTML page, without any server-side script). Other sites must not be allowed access to the file. How does one configure the server to handle this case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Length of LC comment period
On Tue, 8 Dec 2009, Ian Hickson wrote: The requirements were fulfilled, that's why it's ready for LC. It's just not ideal. I'll see if I can come up with some text when I update the spec for LC publication, though. I've added an issue marker before the ToC. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Length of LC comment period
Ian Hickson wrote: On Tue, 8 Dec 2009, Ian Hickson wrote: The requirements were fulfilled, that's why it's ready for LC. It's just not ideal. I'll see if I can come up with some text when I update the spec for LC publication, though. I've added an issue marker before the ToC. Thanks, Ian! you rock! :D Marcos
RE: [public-webapps] Comment on Widget URI (2)
http://tools.ietf.org/html/draft-duerst-iri-bis-07#section-5 gives several different examples of normalization and comparison of strings for the purpose of identification. There are significant differences in alternatives for how to do comparison of Unicode file names. I can't figure out from the document of the Widget: URI scheme which, if any, of the comparison algorithms are recommended. In fact, the assertion that using UTF-8 is recommended seems like it would result in ambiguous interpretation of URIs if some implementations use UTF-8 and others don't. So, if I have a file named Voß.html and a relative IRI that points to voss.html, do they match or not? You say case sensitive, do you mean byte for byte? Do half-width romaji characters match the full-width romaji characters? Note that different operating systems normalize unicode file names differently. Perhaps it's necessary to dig further into the widget spec to insure this is not an ambiguity, but the question was whether the widget specification was well-defined, and my comment was that it didn't seem to be. Larry -- http://larry.masinter.net -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, November 19, 2009 6:00 AM To: Larry Masinter Cc: public-webapps@w3.org Subject: Re: [public-webapps] Comment on Widget URI (2) Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 2) ** WELL-DEFINED MAPPING TO FILES ** Section 4.4 Step 2 makes normative reference: http://www.w3.org/TR/widgets/#rule-for-finding-a-file-within-a-widget- The algorithm there seems to be lacking a clear definition of matches which deals reasonably with the issues surrounding matching and equivalence for Unicode strings, or the handling of character sets in IRIs which are not represented in UTF8. Suggestion (Editorial): Move the definition of the mapping algorithm into the URI scheme registration document so that its definition can be reviewed for completeness. Suggestion (Technical): Define exactly and precisely what match means and make it clear what the appropriate response or error conditions are if there is more than one file that matches. This comment concerns P+C, and I'm unsure about what change you are requesting where. Could you please provide an example of an issue in the current setup and explain how you would like to see it addressed? -- Robin Berjon - http://berjon.com/
Re: Semi-public resources in Uniform Messaging
On Wed, Dec 9, 2009 at 7:43 AM, Ian Hickson i...@hixie.ch wrote: Ok, let's move on to a more complex case. Consider a static resource that is protected by a cookie authentication mechanism. For example, a per-user static feed updated daily on some server by some automated process. The server is accessible on the public Web. The administrator of this service has agreements with numerous trusted sites, let's say a dozen sites, which are allowed to fetch this file using XHR (assuming the user is already logged in). The sites that fetch this file do not require authentication (e.g. one could be my portal page, which is just a static HTML page, without any server-side script). Other sites must not be allowed access to the file. How does one configure the server to handle this case? Again going with the simplest thing that could possibly work: Each of the per-user static feeds is referenced by a unique unguessable URL of the same format used in the previous example. For example, https://example.com/user123/?s=42tjiyrvnbpoal https://example.com/user456/?s=sdfher34nvl34 ... Again, a GET response from such a URL carries the same-origin opt-out header. The user gives this URL only to those services he wants to access the feed. For example, you could copy this URL into your personal static HTML page that acts as your portal. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: Semi-public resources in Uniform Messaging
On Wed, 9 Dec 2009, Tyler Close wrote: On Wed, Dec 9, 2009 at 7:43 AM, Ian Hickson i...@hixie.ch wrote: Ok, let's move on to a more complex case. Consider a static resource that is protected by a cookie authentication mechanism. For example, a per-user static feed updated daily on some server by some automated process. The server is accessible on the public Web. The administrator of this service has agreements with numerous trusted sites, let's say a dozen sites, which are allowed to fetch this file using XHR (assuming the user is already logged in). The sites that fetch this file do not require authentication (e.g. one could be my portal page, which is just a static HTML page, without any server-side script). Other sites must not be allowed access to the file. How does one configure the server to handle this case? Again going with the simplest thing that could possibly work: Each of the per-user static feeds is referenced by a unique unguessable URL of the same format used in the previous example. For example, https://example.com/user123/?s=42tjiyrvnbpoal https://example.com/user456/?s=sdfher34nvl34 ... Again, a GET response from such a URL carries the same-origin opt-out header. The user gives this URL only to those services he wants to access the feed. For example, you could copy this URL into your personal static HTML page that acts as your portal. I think asking users to pass around secret tokens is a non-starter. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [public-webapps] Comment on Widget URI (3)
Your reference to 'every drive-by you should use this! argument' is mainly irrelevant to my comment and I assume your goal was to be insulting, alluding to http://en.wikipedia.org/wiki/Drive-by_shooting -- unless you have some other explanation for your intent? The fact that you got similar requests (that there were multiple drive-by arguments which were just a rehash of something we've seen before) would seem to as likely indicate that there is a significant support for reuse of other schemes, than as a validation of your position that you need a new one. I reviewed the document without having read every other review, and I think that was appropriate. You claim Having done due diligence, but that would seem to make it easy to trivially supply what I asked for and which I cannot infer or guess: a single use case where the offered alternative (thismessage in my case) is inadequate for providing the desired properties of identifiers and their relation to resources. Could you please supply one use case; surely anyone familiar with the lengthy due diligence you allude to would have a simple example? Your previous reply: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0972.html contains interestingly the statement that: # I think that this demonstrates that, technically speaking, # reusing thismessage: *can* be done. It does go on to discuss the costs of doing so, but the costs are all a matter of writing technical specifications and updating the thismessage definition to clarify the ambiguities which you alluded to, and not technical impediments. I had frankly taken your previous note as indicating that you would consider thismessage:/ more carefully. Alternate Suggestion: Withdraw registration of widget: and reference existing scheme. That would leave us with no way of addressing widget resources. Having just now implemented a widget runtime, I don't see how we could have interoperability without them. If you replace the string widget with the string thismessage and remove the possibility of an (opaque, undefined, and unneeded by any documented use cases) authority field, the widget runtimes can proceed, and would have a way of addressing widget resources. There are no apparent use cases where the the string widget: ever appears in any content. If this isn't the case, it isn't clear from the definition of the URI scheme. Rather, it claims # In general, authors of widget content use relative URI references. and # widget URIs identify them only on the inside of a package, irrespective # of that package's own location. and that # Must not require widget developers to be aware of it for basic tasks Since the references are relative, the scheme name shouldn't matter. If it does matter, where? I'll just take your elephant manicures comment as an attempt at humor. Larry -- http://larry.masinter.net -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, November 19, 2009 5:13 AM To: Larry Masinter Cc: public-webapps@w3.org Subject: Re: [public-webapps] Comment on Widget URI (3) Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 3) ** Reuse URI schemes ** http://www.w3.org/TR/webarch/#URI-scheme includes Good practice: Reuse URI schemes A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources. The WebApps WG is well familiar with webarch. In this instance, I would like to emphasise when it provides the desired properties of identifiers and their relation to resources. The WebApps WG has discussed this topic with luminaries and experts in both the TAG and the community at large, and to this date, while we have learnt about many obscure and sometimes poorly defined URI schemes, none has provided us with a solution. We've long reached the point where every drive-by you should use this! argument is just a rehash of something we've seen before. Having done due diligence, I feel confident that we haven't found an existing URI scheme that, as per AWWW, provides the desired properties of identifiers and their relation to resources. The draft suggests there are many other schemes (with merit) already proposed, but that these existing efforts, rather than identify packaged resources from the outside, widget URIs identify them only on the inside of a package, irrespective of that package's own location., but this seems to indicate that the requirements for widget URIs are weaker, not stronger. Actually that wasn't the intended meaning, but since it can be construed thusly (and since you made another comment indicating that it was hard to understand) I have removed this section (it was just meant to be informative anyway). Suggestion: Supply use cases where reuse of existing schemes (including thismessage:/) do not provide the desired properties of
File API: Directories and System
Hi all, as discussed in the joint WebApps API - DAP face to face, here is a rough proposal for the Directories and System parts of the File API: http://dev.w3.org/2009/dap/file-system/file-dir-sys.html There are two entry points. One is through navigator.device.fileSystems(), which upon success lists all available FSs. Naturally that only expected to be exposed in trusted environments (like widgets). The other is a localFS attribute of window that is intended to work in the same manner as localStorage and friends. I expect that this is as far as browsers may be interested in going. I can think of some useful applications for it. Comments are very much welcome, *BUT* it is very much appreciated if they can be made on the DAP's mailing list (public-device-a...@w3.org) rather than here. -- Robin Berjon robineko — hired gun, higher standards http://robineko.com/
RE: [public-webapps] Comment on Widget URI (7)
FWIW, just to be clear: My comments about versioning and version numbers only apply to the URI scheme, and not to language specifications in general. I haven't reviewed any of the other WebApps documents, except in the context of reviewing the URI scheme. In general, I support appropriate use of version numbers in languages and language specifications, especially since documents and file formats have ample opportunities for in-band version indicators. It's unfortunate that URIs, being compact strings, have no place for version indicators. Larry -- http://larry.masinter.net -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, November 19, 2009 4:08 AM To: Larry Masinter Cc: public-webapps@w3.org Subject: Re: [public-webapps] Comment on Widget URI (7) Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 7) ** EDITORIAL TITLE ** Widgets 1.0: Widget URIs the 1.0 might imply some kind of versioning, but there is no versioning of URI schemes. Suggestion: retitle Widget URIs I have provisionally made this change. I agree with Marcos that it would be good to do so throughout the widget family of specifications, especially since there is no reason why versions of its various components need to evolve in synchronised fashion - one could use P+C 4.2 with WARP 2.7. Recommendation to the WG: apply the same change throughout. -- Robin Berjon - http://berjon.com/
Re: The most basic File API use case
On Mon, Dec 7, 2009 at 9:46 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Dec 7, 2009 at 1:51 PM, Peter O. Ussuri uss...@threetags.com wrote: Hi Robin, Thanks for your response! Opera's original file system API also had encoding as part of its call that wrote out text — I think that's a bad idea. If you create a text file/blob, you probably really want all of it to use the same encoding. Allowing it to be specified on all calls is begging for bugs. I think that configuring a builder/writer with that once is safer. Fair point - playing with encoding(s) is probably not the right place here. We thus can have just a binary builder and leave text/strings out of the 'building' process altogether. FileWriter can be instructed later to write/save either a blob or a string. I'm not adverse to appendBinaryString/appendByte but I was sort of hoping that a proposal for binary data in ES would stabilise quickly and that we could just appendBinary(binaryThingie). Apart from these small details I think that the primary distinction between our approaches stems from whether we consider it possible to keep writing to a file after it's been downloaded. I think that there are use cases to allow that, but I equally understand if implementers see it as going somewhat out of the regular download situation and may get anxious about the implication that that might have (which it why I discuss that in my security section, and produced the save/close dichotomy, which I'm not sure I'm entirely happy about). The sort of usage I have in case for continuous writing is 1) load a document (of any kind, possibly big) for editing in your browser; 2) tweak it; 3) save; 4) view it in another application; 5) decide to tweak it some more. A more concrete example could be a browser-based POV editor using WebGL niftiness, and doing renders outside using the POV engine. Without continuous write step (3) involves the download dialog, the file picker, are you sure you want to replace this file prompt at each tweak — it's a usability PITA. I would tend to think that continuous write is not so different from downloading a file without Content-Length — but I'd like some feedback on that. If implementers agree that continuous write is doable, I think we should keep it and from there my proposal to merge our proposals would be to take my draft, turn the BinaryWriter and TextWriter into Binary/TextBlobBuilder equivalents, and provide a way to tie a Blob to a downloaded file. Blobs and File are already linked, so essentially it could just be about adding a flag, or specifying your saveBlobAsFilePrompt to stay manipulatable after save. WDYT? The main reason I introduced the group 0 use case was to make sure a 'minimal' API is agreed upon and implemented by browser vendors, so that developers like myself could start using it. Thus if a proposal for binary data in ES is nowhere near stability (I can't tell), I suggest a simple binaryBuilder/blobBuilder interface is introduced to move things forward. If, on the other hand, there is an alternative way to construct binary data, then of course we should use it and should not create a separate binaryBuilder just for File API. There should be alignment with FileReader, though, and FileReader API already specifies blobs, so BlobBuilder does not look redundant at first glance. My suggestion would be to create a BlobBuilder for now that didn't include methods for BinaryArray (or whatever it'll be called) arguments for now. And just add them once we feel that a spec is stable enough for it. +1. Regarding continuous writing: I agree that there are use cases that would benefit a lot from it, so the behavior should be specified and implemented in some way down the road. However, as you point it out yourself, there are some open issues to be clarified/resolved around it. Thus my suggestion would be to design FileWriter in a way that would keep the continuous writing option on the table, but have a write-and-done method specified now, so that vendors can implement it. I have the same reaction. An API that would allow simply bringing up a safe file as dialog, similar to the dialog used when downloading files, is something that I know we could implement in Firefox right away. Agreed: start simple and then extend later. I lean toward an input element that requires a user action to bring up the dialog box, but I'm still thinking about it. A continuous writing API is something we'd have to develop new security models for, in order to get the user to understand what is happening. Thus I have no idea when or if we'd be able to do that. It's certainly something I'd encourage people to research and think about, but it's something I'd rather not bundle with the simpler API spec-wise. To summarize, my preference would be to have a very basic/simple FileWriter API agreed upon and implemented sooner, and have a more advanced/sophisticated
RE: [public-webapps] Comment on Widget URI (7)
Hi Larry, WOW: It's a pity you were not involved in the discussions around PC's version attribute. Thanks, Marcin From: public-webapps-requ...@w3.org [public-webapps-requ...@w3.org] On Behalf Of Larry Masinter [masin...@adobe.com] Sent: Wednesday, December 09, 2009 7:20 PM To: Robin Berjon Cc: public-webapps@w3.org Subject: RE: [public-webapps] Comment on Widget URI (7) FWIW, just to be clear: My comments about versioning and version numbers only apply to the URI scheme, and not to language specifications in general. I haven't reviewed any of the other WebApps documents, except in the context of reviewing the URI scheme. In general, I support appropriate use of version numbers in languages and language specifications, especially since documents and file formats have ample opportunities for in-band version indicators. It's unfortunate that URIs, being compact strings, have no place for version indicators. Larry -- http://larry.masinter.net -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, November 19, 2009 4:08 AM To: Larry Masinter Cc: public-webapps@w3.org Subject: Re: [public-webapps] Comment on Widget URI (7) Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 7) ** EDITORIAL TITLE ** Widgets 1.0: Widget URIs the 1.0 might imply some kind of versioning, but there is no versioning of URI schemes. Suggestion: retitle Widget URIs I have provisionally made this change. I agree with Marcos that it would be good to do so throughout the widget family of specifications, especially since there is no reason why versions of its various components need to evolve in synchronised fashion - one could use P+C 4.2 with WARP 2.7. Recommendation to the WG: apply the same change throughout. -- Robin Berjon - http://berjon.com/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: The most basic File API use case
On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon ro...@berjon.com wrote:
Hi Peter!
On Dec 7, 2009, at 22:51 , Peter O. Ussuri wrote:
Fair point - playing with encoding(s) is probably not the right place here.
We thus can have just a binary builder and leave text/strings out of the
'building' process altogether. FileWriter can be instructed later to
write/save either a blob or a string.
Actually I've changed my mind here :)
If we have a method that can write out a text file, it simply take a string
(and then indeed a global encoding to apply to all the file). But for blobs,
given that you're writing out binary anyway, it is less important to control
the global encoding. In fact there are probably binary formats that can only
take US-ASCII in place but that might accept UTF-8 elsewhere. See below for
details.
Thus if a proposal for binary data in ES is nowhere near stability (I
can't tell), I suggest a simple binaryBuilder/blobBuilder interface is
introduced to move things forward.
Agreed. My proposal below doesn't have the full details of what can be done
to add some binary, but that can easily be added.
Regarding continuous writing: I agree that there are use cases that would
benefit a lot from it, so the behavior should be specified and implemented
in some way down the road. However, as you point it out yourself, there are
some open issues to be clarified/resolved around it. Thus my suggestion
would be to design FileWriter in a way that would keep the continuous
writing option on the table, but have a write-and-done method specified
now, so that vendors can implement it.
Listening to you and Jonas, that's what I've tried to do now.
Here's roughly what I propose:
First we have a FileWriter. It can save to both text (with options for
encoding and line endings) and to binary (if given a blob). It is designed to
look a lot like FileReader (and thus XHR). That does lead to some amount of
extra verbosity, but I think that the alignment is worth it. Hopefully the
general idea is clear.
[Constructor(DOMString mediaType, DOMString fileName)]
interface FileWriter {
// saving operations
void save (DOMString content, optional DOMString encoding, optional
DOMString endings);
void save (Blob data);
// abort the save
void abort();
// state codes
const unsigned short INITIAL = 0;
const unsigned short WRITING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned short readyState;
// error, same as FileReader but with some additions
readonly attribute FileError error;
// event handler attributes
attribute Function onloadstart;
attribute Function onprogress;
attribute Function onload;
attribute Function onabort;
attribute Function onerror;
attribute Function onloadend;
};
FileWriter implements EventTarget;
Then we have a WritableBlob. I'm not married to the name, I just liked the
approach of having a single object which both contains the data and does the
manipulation, as opposed to the builder object from which you get the content
when you're done. The level of indirection didn't seem necessary, but maybe I
missed something. As I said above, we can have more options as in your
BlobBuilder to add content into it, and we don't have to use overloading if
people don't like it (or if it doesn't scale). If we do stick to overloading
I wouldn't be adverse to adding Constructor(Blob blob) and Constructor(octet
val).
[Constructor]
interface WritableBlob : Blob {
void put (Blob blob);
void put (octet val);
void put (DOMString string, optional DOMString encoding);
};
I've also been wondering if we should add put(Blob... blob), put(octet...
val), put(Blob[] blobs), put(octet[] vals), etc. Again, those are trivial
changes.
Some examples:
// 1. writing out a text file like the one in my FileWriter draft
var str = ;
for (var i = 0; i 10; i++) str += I am dahut number . i . \n;
var fw = new FileWriter(text/plain, ten-dahuts.txt);
fw.onload = function () { alert(File has been saved!); }
fw.onerror = function (err) { alert(Failed to save file: + err.code); }
fw.save(str);
// 2. writing out an image -- it's very much the same
var blob = loadDVDContent(The Blob); // a blob with some video content
var fw = new FileWriter(video/ogg, the-blob.ogg);
fw.onload = function () { alert(Be afraid!); }
fw.onerror = function (err) { alert(Be very afraid!); }
fw.save(blob);
// 3. creating a blob from scratch
var blob = new WritableBlob();
for (var i = 0; i 10; i++) blob.put(i); // a very useful binary file
Thoughts? If people like the general design, I'll make a draft of it and send
it out for review. We can then tweak the various options — but what I'm most
interested in first is getting some consensus around the overall shape of it.
Just making sure I've got the interface clear:
FileWriter doesn't quite correspond to
Re: [widgets] test-cases for icons: some possible errors
On Fri, Dec 4, 2009 at 5:23 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 3 Dec 2009, at 17:26, Marcos Caceres wrote: On Sun, Nov 29, 2009 at 6:03 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Some more potential test case errors and fixes: == bl.wgt ✔ Tests the UA's ability to locate an icon in a locale folder and at the root of the widget. To pass, after processing, the icons list must contain a pointer to locales/en/icon.jpg, and icon.png, which is at the root of the widget. The icons list needs to be in the correct order, where locales/en/icon.jpg must be first and icon.png must be second. Following Step 9 and using Rule for Finding a File Within a Widget Package I always get these the other way around, as icon.png is in front of icon.jpg in the default icons list mmm. I'm not sure I understand how that happens? Section 9.1.3. Rule for Finding a File Within a Widget Package, step 5 in the algorithm should be forcing you to find the localized icon first. Please recheck the spec and I can try to clarify where it is confusing in regards to how files are found (i.e., always localized content first, then followed by unlocalized content) Step 9 is as follows: For each file name in the default icons table (from top to bottom) that has a media type that is supported by the user agent: Let potential-icon be the result of applying the rule for finding a file within a widget package to file name. If the following conditions are all true, then append the value of potential-icon to the icons list of the table of configuration defaults: The value of potential-icon is a file. The potential-icon is a processable file, determined by the media type given in the media type column of the default icons table. The potential-icon does not already exist in the icons list of the table of configuration defaults. Move onto the next file name in the default icons table. So, using this algorithm, pass.png would always come before locales/en/pass.jpg E.g For (icon in icon.svg, icon.ico, icon.png, icon.gif, icon.jpg): A: Looked for icon.svg using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.ico using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.png using the rule in 9.1.3. No localized version, so got root icon.png. B: Appended /icon.png C: Next! A: Looked for icon.gif using the rule in 9.1.3. B: Nope C: Next! A: Looked for icon.jpg using the rule in 9.1.3. Found locales/en/icon.jpg B: Appended locales/en/icon.jpg C: Done! Icons List = icon.png, locales/en/icon.jpg Ah, right you are. Sorry, for some silly reason I thought the test was using custom icons. I'll update the test description tomorrow as I don't have CVS set up on this machine. Apologies also for not replying sooner, I've been on vacation last few days. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] test-cases for icons: some possible errors
On Wed, Dec 9, 2009 at 2:46 PM, Robin Berjon ro...@berjon.com wrote: On Dec 9, 2009, at 14:31 , Cyril Concolato wrote: Actually, I have a problem with the way the test suite result are expressed. Since there is no normative algorithm for the selection of the actual displayed icon, why should the test suite results but so strict. In particular, why does an implementation need to list all icons, if its policy is to select the first one, correct according to the spec, and that matches its needs. For example, one could say: Agreed, I think we should test for what the *first* icon is in the list (the one that's selected). Listing all the others isn't useful, they're never used. I agree that the strict ordering is irrelevant because of the reason Cyril mentioned. And yeah, I agree that having multiple icon choices was probably stupid idea :(But can we give it a month to see if anyone does anything interesting with multiple icons in a list?). If everyone ignores multiple icons, then we will chuck it out. A quicker route might be to ask implementers what they want... I know that Robin wants them gone, at least. Cyril and Scott, is this feature any use to you? I'll ask the Bondi guys (I've CC'd David). -- Marcos Caceres http://datadriven.com.au
