WAF F2F Meeting in Brisbane -- 17 Apr 2007

<artb> Date: 17 April 2007

<artb> Scribe: Cam

<artb> ScribeNick: heycam

RESOLUTION: f2f minutes will be public

AB outlines schedule

AB: widget requirements, we should respond to bert bos' comments
... we'll get in to what's in scope of a widget platform
... anybody have any new inputs?
... guido has a widget signing input he wants to show
... i'd like to go through the red blocks in the spec, try to address the issue / assign an action
... we have quite a few of them
... with xbl2, i know jonas has submitted some comments and hixie hasn't responded yet

<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

AB: testing/interoperability, we should go through some ideas for testing models

<Hixie> (fwiw)

AB: like to get a better sense of implementation plans

MC: LH, AVK and I did some work on the xbl2 primer
... jose responded to my mail

AB: read access control, i have a few editorial comments on the draft
... wasn't clear if all of marc's comments were addressed

AVK: he hasn't responded yet

AB: some open actions to assign to marc
... since BP is leaving, we should close the taskforce
... DFAUI we're no farther ahead than we were in january, which is a big issue
... we'll have those two guys on the call tomorrow
... i'd be interested to get feedback from you guys here in this meeting
... finally, miscellaneous stuff
... charter update, since we're working on some thing which aren't really in the charter
... future f2f meetings, telcon frequency and time
... i'll be making a WAF presentation at WWW2007
... any other items to go through this week?

widgets requirements

AB: we can go through bert's comments one by one

marcos's response to bert will serve as the record of the discussion for this part

AB: let's go through all of the TODOs in the document and see if we can work on them
... has this version we're looking at been checked in?

MC: v1.21 should be up there

<artb> ACTION: Marcos Respond to Bert Bos with the agreements from the April 17 discussion. [recorded in http://www.w3.org/2007/04/17-waf-minutes.html#action01]

<trackbot> Created ACTION-78 - Respond to Bert Bos with the agreements from the April 17 discussion. [on Marcos Caceres - due 2007-04-24].

AB: any blocking things?

MC: mostly cosmetic at the moment, it's starting to get stable
... now we need a lot of work on the spec
... we should keep updating the reqs document, based on what happens to the spec
... we should drop some reqs, based on them being out of scope, e.g. R26 ("accessing services")

AB: you could address it this way: most widget engines provide APIs to platform services, however such APIs are not within the scope of this work

MC: it's not worth dropping, since it's important, ...

AB: did we want to limit this document to only the things we will address in Widgets
... i think it's good to be broader, but clear on which things are in/out of scope
... it's beyond the scope of the Widget packaging format specification
... some other TODOs in the appendices, i think

MC: this stuff i need to integrate in
... i may chuck this out

AB: are you concerend about keeping it up to date?

MC: yeah
... there are sections that are going to take a long time to work out, such as the security model

AB: i'm not sure we could say a lot more from the reqs document about security

MC: microsoft/yahoo lets you do whatever you want, dunno about apple, opera is limited

AB: i'd be ok with leaving the three TODO blocks in the appendices for the next publication

MC: and if i can add more text from my other thing, i will as well

AB: that's pretty much it for the requirements

Widgets spec

MC: looking at the first red block
... we need to define classes of products

AVK: user agents, conformance checkers, authoring tools
... i want to know how we'll progress on this spec
... i don't think we can have complete backwards compatibility with existing impls
... we should look at the widget updating, and if it's too hard, drop it for now
... mobile vs desktop widgets
... we should clearly look at what problems we are trying to solve with widgets
... the basic idea of updating widgets is clear, so i don't think we need to discuss that much
... the moment you get in to signing, updating, states, mobile vs desktop, it becomes more difficult

AB: wrt signing, we have a decent proposal that it would make sense to go through

AVK: there's also the microsoft thing, where they want the packaging as a means for distributing browser plugins

GG: what do we address first?

AVK: we can have a look at your stuff

GG: i think it would be useful if people would read it

AVK: read it tonight, do it tomorrow?

AB: do you want to do a quick intro?

GG: it suggests to use xml signatures and a specific variant of that, where the sig is stored outside the package that is signed

AVK: so that does interact with the updating

GG: it can still be inside the package, but outside of the part that is signed
... i think all the rest is just the details about how xml signatures work
... the normative text is pretty short, at the bottom of the document

AB: should we at a minimum, add another red block in the spec?

AVK: i think updating has a red block
... for downloading a widget, what's the easiest way for authors to do that?
... say you want to provide a separate version as a mobile widget
... do you have some sort of file that indicates use this one?
... or distribute it all in one?

AB: you think the spec should state that?

AVK: dunno

MC: might be part of the request header

AVK: the accept header is broken
... for simple widgets you would want just the one version
... a stock ticker would be easily cross platform
... the aquarium one though, that's quite a big widget
... on mobiles you might want to provide a different version

MC: i don't know if we need to deal with that level of complexity at this point

AVK: might have a startup file chosen based on media query

AB: sounds more like a best practice

AVK: you'd have to define the process of picking one

GG: you're proposing media query syntax in the config file?

AVK: yes
... it doesn't address download size though
... the other similar issue is localised versions of widgets

GG: how would the syntax look like? like the yellow example on the screen? [examples from css3-mediaqueries]

AVK: yes
... 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
... so authors can provide specific versions for mobile, if they really want

GG: an alternative way to do that would be to have the index.html that redirects based on the query

AVK: in theory you could do it that way
... probably doesn't make sense for language

GG: if you have the same simple language, you might not want to duplicate the markup ten times
... you're proposing at install time
... i'm proposing a decision the moment you fire up

AVK: well not install time, also run time

GG: then this config file queries are evaluated when the widget starts

AVK: no, you're right, it would be stored after the initial time you run the widget
... so it is like "install" time

GG: there are some tricky cases, with device rotation changing screen size e.g.

MC: this'd be useful, but might be overkill for version 1

AVK: how do you want to address the mobile versions?

MC: maybe just make two versions of the widget

AVK: authors are giving feedback that they don't want to do that

GG: if you used the discovery mechanism that you use further down, pointing to one package all the time
... unless i have some crappy server side content switching, i always get the same package

MC: the option's always there to make a mobile specific version

GG: yeah, you can still do it in a different package

MC: i only looked at the MQ stuff briefly

GG: it has a very basic set of device properties you can query for
... the dimension ones are the most useful
... 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
... not just the width of the viewport

LH: opera's got most of css3-mq implemented

GG: this is a css parser thing

MC: even if this was proposed for yahoo as well, they're starting to implement css

AB: back to how we advance the widgets spec
... it's not going to advance without input for the red blocks
... helpful to have people commit to giving some input for a block
... or if people think a block should be deleted
... "what does it mean to conform to level 2.0 zip"

MC: there was a problem with deflate64, i think
... i asked some opera engineers, and they didn't tell me why they fear the deflate64
... the other thing is to check this in the mobile space

AB: sounds like an action for me

AVK: is deflate64 patented?

MC: find out what capabilities to decompress zip files in the mobile space

<art> ACTION: barstow What are the ZIP capabilities for Symbian / S60? [recorded in http://www.w3.org/2007/04/17-waf-minutes.html#action02]

<trackbot> Created ACTION-79 - What are the ZIP capabilities for Symbian / S60? [on Arthur Barstow - due 2007-04-24].

AVK: we shouldn't create problems if we're not sure they exist

AB: We support zip.
... you can delete the issue, if that was all that was keeping it there
... when need a separate section about signing

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.
... the processing model

MC: from request all the way to processing
... that's a structure problem, we can get back to later
... next box, folder structure
... that can also be done later
... content type?

AVK: once you have the processing model, you have the mime type

LH: should we define what happens if it's sent with the wrong mime type?

AVK: probably served as application/zip often
... i'm fine with doing things easy for authors
... i dunno how people will react if we define sniffing for widget zip files though
... i'm not sure what the current processing model is. there are lots of ones on opera that have x-opera-widget

LH: that works if you have a central repo

AVK; we also have an offline loading processing model, which is different from the http one

AVK: can drag a config file onto the browser
... it recognises it from the directory structure and name

LH: if it ends in .widget, see if it is an actual widget

next is whether a namespace is needed

AB: can we answer this question?

LH: why would it be useful to have one?

AVK: the answer [to whether we need one] is not clear

LH: only useful in multi-ns documents

AVK: for extensions e.g.

LH: not going to happen in a config file

AB: why don't we try to keep it simple for v1.0?

AVK: i suspect people will object to this

GG: any single widget implementation that uses namespaces?

MC: yes, yahoo, well they have a doctype i think

AB: without a compelling use case...

MC: except extensibility

GG: the only thing for extensibility is to skip over unknown elements

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

GG: there's no schema though

MC: it's part of the processing model

GG: it's not unconforming, that there's an unknown element
... every single widget runtime will have proprietary extensions

AB: hard to imagine that this is a complete set of elements.

AVK: they could propose new elements to the WG

AB: can't get consensus, just leave it as is

GG: i'm talking about schema syntax errors as opposed to xml syntax errors

MC: we need to address that as well, if we put proprietary elements, ...

GG: i want other engines to ignore the unknown elements

AVK: we could look at use cases

GG: like apple, they have a couple of elements related to security, and if we can't agree on that part, ...

AVK: the best thing is default to no security, then have a webkit-security element, e.g.
... vendor prefixes instead of namespaces
... it should be part of the processing model
... if the xml fails to parse, then what should happen
... in opera, if the xml is not wellformed, it doesn't show the widget

AB: wrt licensing and copyright, i thought we talked about an element at one point. it never got added?

MC: no

AVK: not clear how it should work

MC: just text

AB: what's existing practice?

AVK: if others do it, be interesting to see what they do with it
... processed? or for other authors to look at?

LH: like rel=license?

AB: an optional element that might have something in there

AVK: best thing might be to provide a hyperlink

MC: yahoo has a copyright element

AVK: some people had extreme use cases, copyright per file, overboard

AB: so just add a copyright element?

license vs copyright

LH: license would be a link to the actual license text

AVK reads from HTML5, license and copyright act the same

MC: should be license instead of copyright?

MC adds a 'license' element to the spec

AB: next issue in 3.4, the id element
... we skipped the width/height

GG: what do these values mean

AVK: these are authoritative
... you can do window.resize
... if you do that, you can no longer do 100%

AB: why are these two elements MUST?

AVK: opera requires them

MC: if you took them away, what happened?

AVK: it took the size of the previously opened widget

GG: if this is something that is required to be encoded, i think the 100% would be cool

AVK: (actually the default is 200x200)

MC: what about speccing a default value?

AB: seems like it should be left to the implementation
... what additional information do we need for this one?

MC: if the w/h aren't present, it should default to 300x150?

AVK: do we want authors to have different default rendering depending on the device?

MC: css pixels deals with this

AVK: it deals with dpi differences
... width/height of the screen

GG: i don't want to ship 5 versions of the widget because of different screen sizes

AVK: device specific initial widget sizes?
... seems over engineered
... maybe simplest is to have width/height only apply to desktop browsers
... and mobiles default to fullscreen, unless in tiny mode

GG: devices without windowing systems can ignore the dimensions?

LH: if you use css, you could use media queries

AVK: the moment you create the widget, you need to know the width/height
... it only seems to make sense on the desktop
... always display them at the given width/height, unless due to platform constraints you can't

AB: can we add that text?

AVK: might want percentages within width/height

CM asks about aspect ratio constrained widgets

MC writes some text in the spec to capture the width/height discussion

<anne> http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?content-type=text/html;%20charset=utf-8#the-windowlayout

MC: we should consider the scenarios with mobile/desktop further

more discussion about width/height, where we decide they should be attributes instead of elements

AB: next, id element

AVK: until we make an update mechanism, id is dropped
... if someone has a good solution, add it at that point

GG: dashboard have width/height as elements (in info.plist)

AVK: this is for updates, unique id for the widget

MC: yahoo has com.yahoo.widget.... just an identifier

AVK: if the processing model doesn't touch it, it's not useful

LH: how do you know if a widget is a replacement for another?
... firefox extensions use UUIDs

AVK: what if you don't provide one?

GG: how do you update a widget?

AVL: you don't, you just install a new one and de-install the old one

LH: isn't that bad for usability?

AVK: the bad thing is that you don't keep your data
... 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
... replaces the widget files, but keeps the same data

GG: want a mechanism that's not just a download url

AVK: then you need another thing to indicate the version
... something like atom, but that's probably too complex
... maybe just a floating point number?
... or 1.3.20 type of versioning (major/minor/...)

GG: dashboard has that x.y.z notation

LH: maybe id should be an attribute of the widget element

- DRAFT -

WAF F2F Meeting in Brisbane

17 Apr 2007

Attendees

Contents

widgets requirements

Widgets spec

Summary of Action Items

Scribe.perl diagnostic output