IRC log of waf on 2007-04-17

Timestamps are in UTC.

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