00:49:31 RRSAgent has joined #waf 00:49:31 logging to http://www.w3.org/2007/04/17-waf-irc 00:49:50 Meeting: WAF F2F Meeting in Brisbane 00:49:56 Date: 17 April 2007 00:50:00 Chair: Art 00:50:54 Agenda: http://lists.w3.org/Archives/Member/member-accesscontrol-tf/2007Apr/0000.html 00:51:11 Scribe: Cam 00:51:16 ScribeNick: heycam 00:51:58 Lachy has joined #waf 00:52:18 RESOLUTION: f2f minutes will be public 00:53:46 AB outlines schedule 00:54:24 AB: widget requirements, we should respond to bert bos' comments 00:54:50 AB: we'll get in to what's in scope of a widget platform 00:54:59 AB: anybody have any new inputs? 00:55:20 AB: guido has a widget signing input he wants to show 00:56:04 AB: i'd like to go through the red blocks in the spec, try to address the issue / assign an action 00:56:09 AB: we have quite a few of them 00:56:21 AB: with xbl2, i know jonas has submitted some comments and hixie hasn't responded yet 00:56:55 i'm not planning on answering xbl2 comments for some months, at least until we have more implementation feedback and enough changes to warrant going back to last call and sitting through another insane meeting with w3c management 00:56:58 AB: testing/interoperability, we should go through some ideas for testing models 00:57:07 (fwiw) 00:57:12 AB: like to get a better sense of implementation plans 00:57:45 MC: LH, AVK and I did some work on the xbl2 primer 00:57:54 MC: jose responded to my mail 00:58:05 AB: read access control, i have a few editorial comments on the draft 00:58:23 AB: wasn't clear if all of marc's comments were addressed 00:58:36 AVK: he hasn't responded yet 00:58:44 AB: some open actions to assign to marc 00:59:00 AB: since BP is leaving, we should close the taskforce 00:59:23 AB: DFAUI we're no farther ahead than we were in january, which is a big issue 00:59:33 AB: we'll have those two guys on the call tomorrow 00:59:45 AB: i'd be interested to get feedback from you guys here in this meeting 01:00:01 AB: finally, miscellaneous stuff 01:00:13 AB: charter update, since we're working on some thing which aren't really in the charter 01:00:27 AB: future f2f meetings, telcon frequency and time 01:00:36 AB: i'll be making a WAF presentation at WWW2007 01:01:12 AB: any other items to go through this week? 01:01:43 Topic: widgets requirements 01:01:54 AB: we can go through bert's comments one by one 01:03:06 marcos's response to bert will serve as the record of the discussion for this part 01:11:55 artb has joined #waf 03:18:33 marcos_ has joined #waf 04:01:34 RRSAgent, this meeting spans midnight 04:08:37 anne has joined #waf 05:08:51 artb has joined #waf 05:10:14 Topic: Widgets spec 05:10:29 s/spec/requirements/ 05:10:38 AB: let's go through all of the TODOs in the document and see if we can work on them 05:11:16 AB: has this version we're looking at been checked in? 05:11:20 MC: v1.21 should be up there 05:12:07 ACTION: Marcos Respond to Bert Bos with the agreements from the April 17 discussion. 05:12:07 Created ACTION-78 - Respond to Bert Bos with the agreements from the April 17 discussion. [on Marcos Caceres - due 2007-04-24]. 05:13:20 AB: any blocking things? 05:13:28 MC: mostly cosmetic at the moment, it's starting to get stable 05:13:41 MC: now we need a lot of work on the spec 05:13:52 MC: we should keep updating the reqs document, based on what happens to the spec 05:14:20 MC: we should drop some reqs, based on them being out of scope, e.g. R26 ("accessing services") 05:14:44 AB: you address it this way: most widget engines provide APIs to platform services, however such APIs are not within the scope of this work 05:14:50 s/you address/you could address/ 05:14:58 MC: it's not worth dropping, since it's important, ... 05:15:11 AB: did we want to limit this document to only the things we will address in Widgets 05:15:19 AB: i think it's good to be broader, but clear on which things are in/out of scope 05:15:37 AB: it's beyond the scope of the Widget packaging format specification 05:17:21 AB: some other TODOs in the appendices, i think 05:17:28 MC: this stuff i need to integrate in 05:17:56 MC: i may chuck this out 05:18:03 AB: are you concerend about keeping it up to date? 05:18:04 MC: yeha 05:18:06 s/yeha/yeah/ 05:18:24 MC: there are sections that are going to take a long time to work out, such as the security model 05:18:44 AB: i'm not sure we could say a lot more from the reqs document about security 05:19:05 MC: microsoft/yahoo lets you do whatever you want, dunno about apple, opera is limited 05:20:11 AB: i'd be ok with leaving the three TODO blocks in the appendices for the next publication 05:20:36 MC: and if i can add more text from my other thing, i will as well 05:23:50 AB: that's pretty much it for the requirements 05:46:23 Topic: Widgets spec 05:46:33 MC: looking at the first red block 05:48:03 MC: we need to define classes of products 05:49:43 AVK: user agents, conformance checkers, authoring tools 05:55:15 AVK: i want to know how we'll progress on this spec 05:55:37 AVK: i don't think we can have complete backwards compatibility with existing impls 05:56:05 AVK: we should look at the widget updating, and if it's too hard, drop it for now 05:56:11 AVK: mobile vs desktop widgets 05:57:30 AVK: we should clearly look at what problems we are trying to solve with widgets 05:57:57 AVK: the basic idea of updating widgets is clear, so i don't think we need to discuss that much 05:58:18 AVK: the moment you get in to signing, updating, states, mobile vs desktop, it becomes more difficult 05:58:30 AB: wrt signing, we have a decent proposal that it would make sense to go through 05:58:56 AVK: there's also the microsoft thing, where they want the packaging as a means for distributing browser plugins 05:59:13 GG: what do we address first? 05:59:27 AVK: we can have a look at your stuff 05:59:33 GG: i think it would be useful if people would read it 05:59:37 AVK: read it tonight, do it tomorrow? 05:59:45 AB: do you want to do a quick intro? 05:59:58 GG: it suggests to use xml signatures and a specific variant of that, where the sig is stored outside the package that is signed 06:00:06 AVK: so that does interact with the updating 06:00:20 GG: it can still be inside the package, but outside of the part that is signed 06:00:41 GG: i think all the rest is just the details about how xml signatures work 06:00:48 GG: the normative text is pretty short, at the bottom of the document 06:03:39 AB: should we at a minimum, add another red block in the spec? 06:03:45 AVK: i think updating has a red block 06:04:11 AVK: for downloading a widget, what's the easiest way for authors to do that? 06:04:22 AVK: say you want to provide a separate version as a mobile widget 06:04:32 AVK: do you have some sort of file that indicates use this one? 06:04:38 AVK: or distribute it all in one? 06:04:42 AB: you think the spec should state that? 06:04:44 AVK: dunno 06:04:49 MC: might be part of the request header 06:04:57 AVK: request headers are broken 06:05:13 s/request headers are/the accept header is/ 06:05:30 AVK: for simple widgets you would want just the one version 06:06:01 AVK: a stock ticker would be easily cross platform 06:06:15 AVK: the aquarium one though, that's quite a big widget 06:06:26 AVK: on mobiles you might want to provide a different version 06:06:45 MC: i don't know if we need to deal with that level of complexity at this point 06:07:10 AVK: might have a startup file chosen based on media query 06:07:33 AB: sounds more like a best practice 06:07:38 AVK: you'd have to define the process of picking one 06:08:44 GG: you're proposing media query syntax in the config file? 06:08:45 AVK: yes 06:10:30 AVK: it doesn't address download size though 06:10:38 AVK: the other similar issue is localised versions of widgets 06:11:24 GG: how would the syntax look like? like the yellow example on the screen? [examples from css3-mediaqueries] 06:11:25 AVK: yes 06:11:43 AVK: it'd default back to index.html (index.something), but if those elements are present, it'd pick one based on the media queries, in some defined order 06:12:04 AVK: so authors can provide specific versions for mobile, if they really want 06:12:33 GG: an alternative way to do that would be to have the index.html that redirects based on the query 06:12:53 AVK: in theory you could do it that way 06:13:04 AVK: probably doesn't make sense for language 06:13:19 GG: if you have the same simple language, you might not want to duplicate the markup ten times 06:13:26 GG: you're proposing at install time 06:13:31 GG: i'm proposing a decision the moment you fire up 06:13:43 AVK: well not install time, also run time 06:13:56 GG: then this config file queries are evaluated when the widget starts 06:14:07 AVK: no, you're right, it would be stored after the initial time you run the widget 06:14:12 AVK: so it is like "install" time 06:14:26 GG: there are some tricky cases, with device rotation changing screen size e.g. 06:15:07 MC: this'd be useful, but might be overkill for versio n1 06:15:13 s/versio n1/version 1/ 06:15:25 AVK: how do you want to address the mobile versions? 06:15:29 MC: maybe just make two versions of the widget 06:15:35 AVK: authors are giving feedback that they don't want to do that 06:15:56 GG: if you used the discovery mechanism that you use further down, pointing to one package all the time 06:16:06 GG: unless i have some crappy server side content switching, i always get the same package 06:16:34 MC: the option's always there to make a mobile specific version 06:16:40 GG: yeah, you can still do it in a different package 06:16:54 MC: i only looked at the MQ stuff briefly 06:17:01 GG: it has a very basic set of device properties you can query for 06:17:10 GG: the dimension ones are the most useful 06:17:30 GG: there were a couple of other things, i was a member of the DI WG for a while, and they have zillions of properties that they think you should be able to query for 06:17:36 GG: not just the width of the viewport 06:17:54 LH: opera's got most of css3-mq implemented 06:18:04 GG: this is a css parser thing 06:18:21 MC: even if this was proposed for yahoo as well, they're starting to implement css 06:26:58 AB: back to how we advance the widgets spec 06:27:09 AB: it's not going to advance without input for the red blocks 06:27:28 AB: helpful to have people commit to giving some input for a block 06:27:35 AB: or if people think a block should be deleted 06:28:38 AB: "what does it mean to conform to level 2.0 zip" 06:28:49 MC: there was a problem with deflate64, i think 06:29:18 MC: i asked some opera engineers, and they didn't tell me why they fear the deflate64 06:29:29 MC: the other thing is to check this in the mobile space 06:29:36 AB: sounds like an action for me 06:29:50 AVK: is deflate64 patented? 06:30:19 art has joined #waf 06:32:03 MC: find out what capabilities to decompress zip files in the mobile space 06:32:28 ACTION: barstow What are the ZIP capabilities for Symbian / S60? 06:32:28 Created ACTION-79 - What are the ZIP capabilities for Symbian / S60? [on Arthur Barstow - due 2007-04-24]. 06:37:29 AVK: we shouldn't create problems if we're not sure they exist 06:37:38 AB: We support zip. 06:37:51 AB: you can delete the issue, if that was all that was keeping it there 06:38:05 AB: when need a separate section about signing 06:38:47 AVK: i think we need an authoring section that says how to construct a widget, and another section, that says how to read the zip, parse the file, etc. 06:38:56 AVK: the processing model 06:39:05 MC: from request all the way to processing 06:39:22 MC: that's a structure problem, we can get back to later 06:39:49 MC: next box, folder structure 06:39:54 MC: that can also be done later 06:40:58 MC: content type? 06:41:13 AVK: once you have the processing model, you have the mime type 06:41:21 LH: should we define what happens if it's sent with the wrong mime type? 06:41:30 AVK: probably served as application/zip often 06:41:44 AVK: i'm fine with doing things easy for authors 06:41:54 AVK: i dunno how people will react if we define sniffing for widget zip files though 06:42:18 AVK: i'm not sure what the current processing model is. there are lots of ones on opera that have x-opera-widget 06:42:27 LH: that works if you have a central repo 06:42:39 AVK; we also have an offline loading processing model, which is different from the http one 06:42:45 AVK: can drag a config file onto the browser 06:42:53 AVK: it recognises it from the directory structure and name 06:43:18 LH: if it ends in .widget, see if it is an actual widget 06:45:24 next is whether a namespace is needed 06:45:29 AB: can we answer this question? 06:45:38 LH: why would it be useful to have one? 06:45:45 AVK: the answer [to whether we need one] is not clear 06:45:52 LH: only useful in multi-ns documents 06:45:55 AVK: for extensions e.g. 06:45:59 LH: not going to happen in a config file 06:46:08 AB: why don't we try to keep it simple for v1.0? 06:46:18 AVK: i suspect people will object to this 06:46:28 GG: any single widget implementation that uses namespaces? 06:47:02 MC: yes, yahoo, well they have a doctype i think 06:47:37 AB: without a compelling use case... 06:47:41 MC: except extensibility 06:47:56 GG: the only thing for extensibility is to skip over unknown elements 06:48:44 MC: we say this is an xml document, but we're going to say to do error handling, in as far as if you put in elements that are not recognised 06:48:47 GG: there's no schema though 06:49:12 MC: it's part of the processing model 06:49:31 GG: it's not unconforming, that there's an unknown element 06:49:45 GG: every single widget runtime will have proprietary extensions 06:50:04 AB: hard to imagine that this is a complete set of elements. 06:50:17 AVK: they could propose new elements to the WG 06:50:39 AB: can't get consensus, just leave it as is 06:51:10 GG: i'm talking about schema syntax errors as opposed to xml syntax errors 06:51:34 MC: we need to address that as well, if we put proprietary elements, ... 06:51:46 GG: i want other engines to ignore the unknown elements 06:52:30 AVK: we could look at use cases 06:52:54 GG: like apple, they have a couple of elements related to security, and if we can't agree on that part, ... 06:53:13 AVK: the best thing is default to no security, then have a webkit-security element, e.g. 06:53:18 AVK: vendor prefixes instead of namespace 06:53:23 s/namespace/namespaces/ 06:54:07 AVK: it should be part of the processing model 06:54:17 AVK: if the xml fails to parse, then what should happen 06:54:42 AVK: in opera, if the xml is not wellformed, it doesn't show the widget 06:56:12 AB: wrt licensing and copyright, i thought we talked about an element at one point. it never got added? 06:56:13 MC: no 06:56:17 AVK: not clear how it should work 06:56:20 MC: just text 06:56:29 AB: what's existing practice? 06:56:44 AVK: if others do it, be interesting to see what they do with it 06:56:51 AVK: processed? or for other authors to look at? 06:56:58 LH: like rel=license? 06:57:12 AB: an optional element that might have something in there 06:57:22 AVK: best thing might be to provide a hyperlink 06:57:34 MC: yahoo has a copyright element 06:57:48 AVK: some people had extreme use cases, copyright per file, overboard 06:58:16 AB: so just add a copyright element? 06:58:36 license vs copyright 06:58:42 LH: license would be a link to the actual license text 06:59:06 AVK reads from HTML5, license and copyright act the same 06:59:38 MC: should be license instead of copyright? 07:01:14 MC adds a 'license' element to the spec 07:03:35 heycam has changed the topic to: Brisbane F2F 07:04:43 AB: next issue in 3.4, the id element 07:05:11 AB: we skipped the width/height 07:07:35 GG: what do these values mean 07:07:55 AVK: these are authoritative 07:07:59 AVK: you can do window.resize 07:08:16 AVK: if you do that, you can no longer do 100% 07:08:24 AB: why are these two elements MUST? 07:08:38 AVK: opera requires them 07:08:47 MC: if you took them away, what happened? 07:08:53 AVK: it took the size of the previously opened widget 07:09:17 GG: if this is something that is required to be encoded, i think the 100% would be cool 07:09:26 AVK: (actually the default is 200x200) 07:10:32 MC: what about speccing a default value? 07:10:48 AB: seems like it should be left to the implementation 07:12:01 AB: what additional information do we need for this one? 07:12:32 MC: if the w/h aren't present, it should default to 300x150? 07:12:56 AVL: do we want authors to have different default rendering depending on the device? 07:13:09 MC: css pixels deals with this 07:13:14 AVK: it deals with dpi differences 07:13:16 s/AVL/AVK/ 07:13:22 AVK: width/height of the screen 07:13:47 GG: i don't want to ship 5 versions of the widget because of different screen sizes 07:15:20 AVK: device specific initial widget sizes? 07:15:26 AVK: seems over engineered 07:15:49 AVK: maybe simplest is to have width/height only apply to desktop browsers 07:16:02 AVK: and mobiles default to fullscreen, unless in tiny mode 07:16:21 GG: devices without windowing systems can ignore the dimensions? 07:16:50 LH: if you use css, you could use media queries 07:17:26 AVK: the moment you create the widget, you need to know the width/height 07:17:30 AVK: it only seems to make sense on the desktop 07:18:28 AVK: always display them at the given width/height, unless due to platform constraints you can't 07:18:35 AB: can we add that text? 07:18:43 AVK: might want percentages within width/height 07:21:23 CM asks about aspect ratio constrained widgets 07:24:36 MC writes some text in the spec to capture the width/height discussion 07:29:22 http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?content-type=text/html;%20charset=utf-8#the-windowlayout 07:29:24 MC: we should consider the scenarios with mobile/desktop further 07:37:17 more discussion about width/height, where we decide they should be attributes instead of elements 07:38:29 AB: next, id attribute 07:38:46 AVK: until we make an update mechanism, id is dropped 07:39:01 AVK: if someone has a good solution, add it at that point 07:39:15 GG: dashboard have width/height as elements (in info.plist) 07:41:18 s/id attribute/id element/ 07:41:33 AVK: this is for updates, unique id for the widget 07:42:17 MC: yahoo has com.yahoo.widget.... just an identifier 07:42:55 AVK: if the processing model doesn't touch it, it's not useful 07:43:07 LH: how do you know if a widget is a replacement for another? 07:43:29 LH: firefox extensions use UUIDs 07:43:41 AVK: what if you don't provide one? 07:43:46 GG: how do you update a widget? 07:43:55 AVL: you don't, you just install a new one and de-install the old one 07:43:58 LH: isn't that bad for usability? 07:44:12 AVK: the bad thing is that you don't keep your data 07:44:33 AVK: maybe the use case is that you have the identifier, and the UA makes it clear that this new widget will replace the old one 07:44:41 AVK: replaces the widget files, but keeps the same data 07:45:35 GG: want a mechanism that's not just a download url 07:46:01 AVK: then you need another thing to indicate the version 07:46:09 AVK: something like atom, but that's probably too complex 07:46:17 AVK: maybe just a floating point number? 07:46:34 AVK: or 1.3.20 type of versioning (major/minor/...) 07:47:48 GG: dashboard has that x.y.z notation 07:48:44 LH: maybe id should be an attribute of the widget element 07:52:46 07:57:20 RRSAgent, make minutes 07:57:20 I have made the request to generate http://www.w3.org/2007/04/17-waf-minutes.html heycam 08:00:12 RRSAgent, make logs public 08:02:04 Present: Art, Cam, Lachlan, Marcos, Anne, Guido 08:02:19 RRSAgent, make minutes 08:02:19 I have made the request to generate http://www.w3.org/2007/04/17-waf-minutes.html art 08:03:50 ACTION: Barstow send April 17 minutes to the Public Mail List 08:03:50 Created ACTION-80 - Send April 17 minutes to the Public Mail List [on Arthur Barstow - due 2007-04-24]. 08:04:24 RRSAgent, bye 08:04:24 I see 3 open action items saved in http://www.w3.org/2007/04/17-waf-actions.rdf : 08:04:24 ACTION: Marcos Respond to Bert Bos with the agreements from the April 17 discussion. [1] 08:04:24 recorded in http://www.w3.org/2007/04/17-waf-irc#T05-12-07 08:04:24 ACTION: barstow What are the ZIP capabilities for Symbian / S60? [2] 08:04:24 recorded in http://www.w3.org/2007/04/17-waf-irc#T06-32-28 08:04:24 ACTION: Barstow send April 17 minutes to the Public Mail List [3] 08:04:24 recorded in http://www.w3.org/2007/04/17-waf-irc#T08-03-50