W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

[widgets] Draft Minutes for 3 November 2009 f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 3 Nov 2009 21:44:22 -0800
Message-Id: <656FB585-F65B-4000-8FB4-3A06412FCE9E@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the November 3 Widgets f2f meeting are  
available at the following and copied below:

  http://www.w3.org/2009/11/03-wam-minutes.html **

WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before November 12 (the next  
Widgets voice conference); otherwise these minutes will be considered  

-Regards, Art Barstow

** The date on the HTML page says "2 November" but should say "3  
November. That bug will be fixed. The date is correct in the minutes  



       [1] http://www.w3.org/

                                - DRAFT -

                Widgets F2F Meeting in Santa Clara CA US

03 Nov 2009


       [2] http://www.w3.org/2008/webapps/wiki/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2009/11/03-wam-irc


           Art, Josh, Benoit, Marcos, Jere, Arve, Magnus, Jean-Pierre,




      * [4]Topics
          1. [5]Packaging and Configuration spec
          2. [6]View Modes Media Feature
          3. [7]AOB
          4. [8]TWI spec
          5. [9]TWI attributes
          6. [10]Hixie: Invited Guest
          7. [11]Widgets Planning
      * [12]Summary of Action Items

    <scribe> Scribe: Art

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

    Date: 2 November 2009

Packaging and Configuration spec

    AB: P+C Test Suite is first topic

    MC: I made some tests pre Dusseldorf
    ... at that test fest a bunch of tests were created
    ... I have cleaned those tests
    ... We now have Present Technologies people helping
    ... I create the test cases
    ... Present Technologies then checks the test cases and runs them
    ... So far they have tested Windows Mobile 6.5 using emulator
    ... Blackberry emulator


      [13] http://samaxes.svn.beanstalkapp.com/ 

    MC: the Present Technology guys are now Invited Experts
    ... they have found some issues with the test cases
    ... they have found some bugs but nothing serious
    ... we haven't yet moved over the stuff from PT to CVS

    AB: do you need help from the Team?

    <scribe> ACTION: smith work with Marcos to get test stuff from
    Present Technologies moved to CVS [recorded in

    <trackbot> Created ACTION-435 - Work with Marcos to get test stuff
    from Present Technologies moved to CVS [on Michael(tm) Smith - due

    MC: we want to make the Compat Matrix made Public
    ... some stuff cannot be tested because of the way we created the
    test suite

    AB: what's an example of something that cannot be tested?

    MC: there is no need for a P+C UA to test TWI dependency
    ... we want the test cases to all be verified

    BS: should the "can't test" test cases be put in a different test

    MC: no, I want these tests in the core P+C test suite
    ... their coverage of test runs is getting pretty good
    ... also tested LG, BONDI and Wookie

    AB: so the next step is to get all of this to CVS?

    MC: yes

    AB: what about the BONDI impl?

    MC: it is running in an emulator

    DR: we are thankful for this work
    ... if you need anything from us, let us know

    MC: there are some prereqs
    ... UA must support HTML4.01, CSS1, PNG, ISO-8859-1
    ... for example must be able to display
    ... and support Red, Green
    ... we want to implementations to support "feature:a9bb79c1
    ... to support the feature element
    ... must be able to support the "en" locale
    ... Eventually, we can create an Acid Test and it will have more
    thorough L10N tests

    DR: re this featue: a9*, what does impl need?

    MC: just need to return true
    ... test suite is:
    ... there are 4 testable assertions that need to be written
    ... when I finish there will be about 16 more tests
    ... results are all in an XML file

      [15] http://dev.w3.org/2006/waf/widgets/test-suite/

    AB: is the MWTS WG still helping with P+C test suite?

    MC: no, Kai is working on the DigSig test suite
    ... the main goal is to be able to test interop
    ... I think the suite will do that

    AB: any questions or comments?

    MC: I need feedback from implementors

    DR: the RIM stuff gets compiled into a JAR
    ... so how do you test?

    MC: we test via their emulator
    ... it is no longer a req that a UA be able to download a package
    from the Web

    AB: after CR#2 we would have some type of interop fest?

    MC: yes and Present Technologies is willing to host it

    AB: if we use the same Exit Criteria as CR#1, we need 2 impls

    DR: we should have a RI by December for BONDI 1.01

    s/BOND 1.01/BONDI 1.1/

    <drogersuk> The BONDI Candidate Release for 1.1 (released today):

      [16] http://bondi.omtp.org/1.1/CR/

    <scribe> ACTION: barstow work on an interop plan for P+C spec
    [recorded in

    <trackbot> Created ACTION-437 - Work on an interop plan for P+C spec
    [on Arthur Barstow - due 2009-11-10].

    AB: when will the test suite be complete?

    MC: next week
    ... want to publish test suite when we publish CR#2

    MO: earlier today I sent some P+C comments to public-webapps
    ... re SVG icons and width and height

    MC: there is a viewport

    [ Marcos displays section 7.11.1 ]

    scribe: I will respond to the email after it shows up on the

    AB: anything else on P+C?

    [ None ]

    AB: input always welcome!

View Modes Media Feature

    AB: there are comments from Marcin and David
    ... and Magun had some comments
    ... MC wants to delete the view mode values from P+C

    MC: I already did that

    AB: the P+C spec was never going to tell a WUA what to do with them
    so this deletion is OK

    MC: yes, that's right and the mistake was to list them
    ... but I've fixed that
    ... one issue here is the default view mode in the Table of Config
    ... currently it says default is "floating"
    ... but I'm proposing it be changed to null

    AB: would this change an impl?

    MC: no because a WUA would just ignore it

    AB: so your proposal is in CR#2 to change the default to "null"
    ... does anyone object to changing the default value of viewmodes to
    ... this means the impl will do-the-right-thing

    [ No Objection]

    RESOLUTION: the viewmode default will be changed to "null"

    AB: so MH on Oct 5 wrote:
    ... and there have been no responses
    ... my take on these comments is they will affect VM-MF and/or VM-I
    but not P+C spec

      [18] http://lists.w3.org/Archives/Public/public-webapps/ 

    MC: using "all" in this email is equiv to "null" i.e. leave it to
    the impl

    AB: David had comments on VMMF on Oct 22:
    ... I think this email raises a couple of questions: do we need
    generic widget security guidelines and does the VMMF spec need some
    security considerations

      [19] http://lists.w3.org/Archives/Public/public-webapps/ 

    [ Marcos shows some images of S60 Widgets ]

    DR: we have discussed a widget security guidelines document
    ... my email about VMMF talks about some scenarios to consider

    AB: we can have sec considerations per spec
    ... and if something doesn't fit, document it separately

    DR: I'm OK with have a Sec Consids section per spec
    ... I sent some info to Marcos

    [ Josh and David talk about various security scenarios ... ]

    DR: I think we need to document some basic security considerations
    ... I have some examples in the social engr context


    AB: on Tues afternoon, want to swap the 15:30-16:30 and 16:30-17:30
    ... we will have Widget planning at 15:30-16:30
    ... any objections?

    [ None ]

    AB: meeting adjourned

    <arve> (and is the bridge up?)

    <arve> I have a very young working group-member-by-extension here
    attempting to say hi

    <scribe> Scribe: Art

    <scribe> ScribeNick: ArtB

    Date: 3 November 2009

    <scribe> Meeting: Widgets Voice Conf

    <scribe> Agenda:

      [20] http://www.w3.org/2008/webapps/wiki/ 

TWI spec

    ... any change requests?

      [21] http://www.w3.org/2008/webapps/wiki/ 

    [ None ]

    AB: the latest ED [22]http://dev.w3.org/2006/waf/widgets-api/
    ... is 19 October your latest version MC?

      [22] http://dev.w3.org/2006/waf/widgets-api/

    MC: yes, that's the latest modulo some editorial changes

    AB: the email MC just sent to the list is:

      [23] http://lists.w3.org/Archives/Public/public-webapps/ 

    MC: the main reason we need Instance defined
    ... is it tells how the widget operates
    ... the specs have some built in assumptions
    ... i.e. some things are assumed

    <arve> do we want to _allow_ navigation?

    MC: a single package could have multiple instances
    ... each instance must have a unique storage
    ... this can also affect the viewport

    Arve: I'm puzzled by why this isn't just a WUA problem

    BS: affects what is in the package

    <arve> a+

    JS: can't we just take care of this via a test

    MC: must define the navigation model

    Arve: that is a different issue
    ... I see the need for links to be handeld the same way
    ... but as for defining widget instance
    ... not sure we need to do that
    ... Opera's UA allows multiple instnaces of the same widget

    MC: agree but we don't want to restrict

    AB: does the text restrict it now?

    MC: no, it doesn't restrict it in any way
    ... so it may be a non-issue
    ... but we do need a definition

    Arve: how does the spec deal with referencing resources in the

    MC: the TWI spec doesn't address that issue
    ... but the URI Scheme spec does

    AB: let's capture the issue now
    ... proposed text: make sure the URI Scheme spec facilitates widget
    instance navigation

    <Marcos> I.e., the spec needs to make it clear how to resolve
    relative paths

    AB: is this right?

    ISSUE: the URI Scheme spec needs to make it clear how to resolve
    relative paths

    <trackbot> Created ISSUE-109 - The URI Scheme spec needs to make it
    clear how to resolve relative paths ; please complete additional
    details at [24]http://www.w3.org/2008/webapps/track/issues/109/edit

      [24] http://www.w3.org/2008/webapps/track/issues/109/edit

    AB: if we look at the current defn of Widget Instance, what needs to

    MC: we need a clear definition
    ... make it clear how instance relates to the DefaultView, Viewport
    and Document

    JS: Window is the global object
    ... what is ViewPort

    MC: it's for styling

    <arve> I would like to point out that two window instances of the
    same URI, in HTML5 terms, can access each other's data

    <arve> we would not like that to happen with separate widget

    JS: when a UA instantiates a widget, by loading the default URI
    ... it applies the widget interface to the Window object
    ... For any page loaded as the top-level resource into the widgets
    ... if the location is same origin to the widget instance then this
    rule always applies
    ... the above is mostly right but needs some editorial changes
    ... some other things are also bound

    <timeless_mbp> Any other widget specifications which specify
    bindings to objects have the opportunity to bind their Interfaces at
    this time according to the same rule

    MC: we want to use the storage attribute that behaves the same as
    local storage or session storage - whichever one persists thru
    navigation of page to page

    JK: this is localStorage then that we want

    AB: so not sessionStorage but localStorage?

    MC: yes

    [ We view Web Storage spec ...
    [25]http://dev.w3.org/html5/webstorage/ ]

      [25] http://dev.w3.org/html5/webstorage/

    AB: so going back to MC's email today:

      [26] http://lists.w3.org/Archives/Public/public-webapps/ 

    <arve> [no comment]

    MC: yes, sessionStorage isn't what we need

    AB: do you now have enough feedback for points 1-4?

    MC: yes, I do

    AB: let's move to point 5

    JS: I claim this is an impl detail

    <arve> +1

    MC: I agree

    BS: should the spec say something about cloning?

    MC: no, that would be too much detail

    JS: yes I agree; we don't want to go there

    Arve: may want to use "top browsing context" here as defined in

    <arve> top level*

    JS: yes, good idea; that could be used instead of the text I
    proposed earlier

    <timeless_mbp> "top-level browsing context"

    AB: what about point #6?

    <arve> "The browsing context with no parent browsing context is the
    top-level browsing context of all the browsing contexts nested
    within it"

    <arve> :D

    AB: would #6 be too restrictive?

    <arve> 6 is, IMO; out of scope for TWI

    <timeless_mbp> If we imagined a Widget impl modeled after Maemo 5

    <timeless_mbp> which doesn't actually follow the behavior described
    in 6

    <timeless_mbp> as it happens, no one likes this inconsistent

    <timeless_mbp> I could demo this unsatisfactory behavior for people

    <timeless_mbp> ----

    <timeless_mbp> It's out of scope, but basically I doubt any widget
    instance is likely to be foolish enough to choose not to get this

    <timeless_mbp> otoh, it's free to lose while competing in the market

    MC: I agree this doesn't need to be in the spec
    ... but we need to make sure we don't explicitly preclude it
    ... browsing context is a concept
    ... and the WindowProxy is the thing that can then be operated upon

    JS: we may want to bind on WindowProxy but I'm not sure

    [ We look at Browsing Context in HTML5
    [27]http://www.w3.org/html/wg/html5/ ]

      [27] http://www.w3.org/html/wg/html5/

    MC: we may be able to use DOM L2 View spec
    ... I need to read this part of HTML5

    <arve> Again, if the widget interface spec needs to reference DOM
    L2, it's a separate spec

    MC: need to understand all of the relationships

    <arve> (It actually is, if we reference CSS-anything as well)

    Arve: if need to reference CSS2 or DOML2 View, need a new spec

    MC: yes, true
    ... we may want to stay silent and just focus on the storage

    <annevk> DOM2 View will be obsoleted fwiw

    <annevk> (its concept of views, anyway)

    <Marcos> annevk: what supersedes it?

    <annevk> CSSOM View

    <Marcos> ok

    MC: view and default view are defined by HTML5

    <annevk> (HTML5 will remove its concept of views too, accordingly)

    <scribe> ACTION: marcos work with Hixie and Anne on a definition of
    Widget Instance [recorded in

    <trackbot> Created ACTION-438 - Work with Hixie and Anne on a
    definition of Widget Instance [on Marcos Caceres - due 2009-11-10].

TWI attributes

    MC: I get questions about why some of the metadata in the config
    file is not an attribute of the Widget object

    <arve> no

    <arve> Baby cried

    BS: how about just adding all of them?

    AB: and just making them DOMStrings

    <arve> But, read the context, and would not object

    AB: propose add license and short name to the Widget object as new
    ... any objections?

    RESOLUTION: will add license and short name to the Widget object as
    new attributes

    BS: what about icons?

    MC: I don't want to add them until we have a proper API
    ... the icons are complicated

    AB: Marcin's comment #1 Sep 23:
    ... Marcin's comment #2 Sep 23:

      [29] http://lists.w3.org/Archives/Public/public-webapps/ 
      [30] http://lists.w3.org/Archives/Public/public-webapps/ 

    MC: those two threads are related to VMMF and VMI specs

    AB: so not TWI?

    MC: correct, not TWI

    AB: Dom did some TWI test work:

      [31] http://lists.w3.org/Archives/Public/public-webapps/ 

    MC: these tests dont' really help to verify the spec
    ... not clear if I'll be able to use what he has done
    ... but I won't know for sure until I do a deep dive on it

    AB: anything else about TWI?

    MC: no, I think we've covered the main points
    ... after I have defined Instance and its relationship to origin and
    URI spec, we'll be done
    ... I need to talk to Robin about it

    AB: so the status is that MC needs to do some work before the spec
    will be ready for a new review
    ... It will probably take me about two weeks before the spec is
    ready for review
    ... anything else on TWI for today?

    <arve> That was the session from 11:00 to 13:00?

    <arve> Just said: Have fun, resolve all issues.

    <arve> Byebye

    <scribe> Chair: Art

    Date: 3 November 2009

Hixie: Invited Guest

    [ MC explains the 1 package 3 instances scenario to Hixie ... ]

    MC: each instance has its own localStorage
    ... Zip has multiple HTML files
    ... want to use the "right" terminology from HTML5

    IH: the circles/instances are top-level browsing context

    MC: are these TLBC's WindowProxy or something else

    IH: any BC has a WindowProxy object
    ... a session history is bound to a BC

    MC: the BC is an abstract concept

    IH: the BC is accessible from script via Window
    ... can only compare WindowProxy
    ... a BC has a session history
    ... do these instances have back and forward?

    MC: yes they do

    IH: session history is a list of docs but has other things
    ... two entries in sess history
    ... each doc in the history has a Window object

    JS: we want to add some properties to Window or WindowProxy

    MC: origin retention is important

    IH: origin is an opaque identifier derived from the UUID

    JS: we are just saying its an opaque id

    IH: any resources loaded from the instance will have the same origin

    MC: so, we just need to talk about TLBC

    JS: and the properties are off the Window object

    IH: take a look at Window Modal IDL

    <Hixie> this is the WindowModal example i was talking about:

      [32] http://www.whatwg.org/specs/web-apps/current-work/ 

    MC: next problem is ViewPort
    ... we want to reuse existing spec if we can

    IH: want to create an @viewport rule

    MC: we need viewport landscape, portrait

    IH: CSS already defines viewport

    MC: we need to define viewport rule to work for web pages and not
    just widgets

    [ Josh demos orientation changes with mobile device ]

    IH: you should probably talk to the CSS WG

    MC: we will say widget prefs will be localStorage

    <timeless> anyone here?

    <MikeSmith> yeah

    <timeless> we'll be there in 5mins

    <timeless> liar

    <MikeSmith> heh

Widgets Planning

    AB: widgets pub status is:

      [33] http://www.w3.org/2008/webapps/wiki/ 

    BS: I will upload an image of MC's diagram from earlier today

    MC: I'll add it to the TWI spec


      [34] http://www.slideshare.net/bsuzanne/widget-instance-model

    <scribe> ACTION: barstow determine a plan for P+C CR#2 and beyond
    [recorded in

    <trackbot> Created ACTION-443 - Determine a plan for P+C CR#2 and
    beyond [on Arthur Barstow - due 2009-11-11].

    MC: there are too many issues with adding license to the Widget

    AB: any objections to keeping it out?

    <scribe> ACTION: benoit submit a proposal for adding license to the
    Widget object [recorded in

    <trackbot> Created ACTION-444 - Submit a proposal for adding license
    to the Widget object [on Benoit Suzanne - due 2009-11-11].

    <scribe> ACTION: marcos to remove license from the ED of the P+C
    [recorded in

    <trackbot> Created ACTION-445 - Remove license from the ED of the
    P+C [on Marcos Caceres - due 2009-11-11].

    <scribe> ACTION: barstow send a request for pre-LC comments for the
    TWI spec [recorded in

    <trackbot> Created ACTION-446 - Send a request for pre-LC comments
    for the TWI spec [on Arthur Barstow - due 2009-11-11].

    <scribe> ACTION: barstow send a reminder to review URI scheme spec
    [recorded in

    <trackbot> Created ACTION-447 - Send a reminder to review URI scheme
    spec [on Arthur Barstow - due 2009-11-11].

    MC: my prios are: P+C test suite, TWI spec
    ... need to spend time on test suite for DigSig

    <scribe> ACTION: barstow review DigSig test suite; get comments from
    Frederick [recorded in

    <trackbot> Created ACTION-448 - Review DigSig test suite; get
    comments from Frederick [on Arthur Barstow - due 2009-11-11].

    MC: Opera opposes URI and WARP going to CR without a prior test
    ... I think these two will be relatively easy to test
    ... will need to discuss with Robin
    ... may need to get some help from Consortium to set up a persistent
    test domain
    ... but that will be needed by CORS, XHR, etc.

    AB: Meeting Adjourned

Summary of Action Items

    [NEW] ACTION: barstow determine a plan for P+C CR#2 and beyond
    [recorded in
    [NEW] ACTION: barstow review DigSig test suite; get comments from
    Frederick [recorded in
    [NEW] ACTION: barstow send a reminder to review URI scheme spec
    [recorded in
    [NEW] ACTION: barstow send a request for pre-LC comments for the TWI
    spec [recorded in
    [NEW] ACTION: barstow work on an interop plan for P+C spec [recorded
    in [45]http://www.w3.org/2009/11/03-wam-minutes.html#action02]
    [NEW] ACTION: benoit submit a proposal for adding license to the
    Widget object [recorded in
    [NEW] ACTION: marcos to remove license from the ED of the P+C
    [recorded in
    [NEW] ACTION: marcos work with Hixie and Anne on a definition of
    Widget Instance [recorded in
    [NEW] ACTION: smith work with Marcos to get test stuff from Present
    Technologies moved to CVS [recorded in

    [End of minutes]
Received on Wednesday, 4 November 2009 05:45:51 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC