<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

<Marcos> http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/index.html

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 http://www.w3.org/2009/11/03-wam-minutes.html#action01]

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

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 suite?

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: http://dev.w3.org/2006/waf/widgets/test-suite/
... 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

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): http://bondi.omtp.org/1.1/CR/

<scribe> ACTION: barstow work on an interop plan for P+C spec [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action02]

<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 reflector

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 Defaults
... 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 null?
... 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: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0047.html
... 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

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: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0292.html
... 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

[ 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

AOB

AB: on Tues afternoon, want to swap the 15:30-16:30 and 16:30-17:30 slots
... 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: http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Tuesday.2C_November_3

TWI spec

AB: http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#The_widget_Interface_.28TWI.29_spec
... any change requests?

[ None ]

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

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

AB: the email MC just sent to the list is: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0459.html

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 package?

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 http://www.w3.org/2008/webapps/track/issues/109/edit .

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

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 instances

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 ... http://dev.w3.org/html5/webstorage/ ]

AB: so going back to MC's email today: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0459.html

<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 HTML5

<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 behavior

<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 right

<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 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 http://www.w3.org/2009/11/03-wam-minutes.html#action03]

<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 attributes
... 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: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1203.html
... Marcin's comment #2 Sep 23: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1205.html

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: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0405.html

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: http://www.whatwg.org/specs/web-apps/current-work/#windowmodal

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: http://www.w3.org/2008/webapps/wiki/PubStatus#Widgets_Specifications

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

MC: I'll add it to the TWI spec

<Benoit> http://www.slideshare.net/bsuzanne/widget-instance-model

<scribe> ACTION: barstow determine a plan for P+C CR#2 and beyond [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action04]

<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 object

AB: any objections to keeping it out?

<scribe> ACTION: benoit submit a proposal for adding license to the Widget object [recorded in http://www.w3.org/2009/11/03-wam-minutes.html#action05]

<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 http://www.w3.org/2009/11/03-wam-minutes.html#action06]

<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 http://www.w3.org/2009/11/03-wam-minutes.html#action07]

<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 http://www.w3.org/2009/11/03-wam-minutes.html#action08]

<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 http://www.w3.org/2009/11/03-wam-minutes.html#action09]

<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 suite
... 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

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/BOND 1.01/BONDI 1.1/
Found Scribe: Art
Found ScribeNick: ArtB
Found Scribe: Art
Found Scribe: Art
Found ScribeNick: ArtB

WARNING: Dash separator lines found.  If you intended them to mark
the start of a new topic, you need the -dashTopics option.
For example:
        <Philippe> ---
        <Philippe> Review of Action Items

Default Present: arve, Widgets

WARNING: Replacing previous Present list. (Old list: Art, Josh, Benoit, David, Marcos, Magnus)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Art, Josh, Benoit, Marcos, Jere, Arve, Magnus, Jean-Pierre

Present: Art Josh Benoit Marcos Jere Arve Magnus Jean-Pierre Hixie
Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Agenda_Items
Found Date: 02 Nov 2009
Guessing minutes URL: http://www.w3.org/2009/11/03-wam-minutes.html
People with action items: barstow benoit marcos smith with work