W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

[widgets] Minutes from 14 August 2008 Voice Conference

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 14 Aug 2008 09:21:46 -0400
Message-Id: <95B77099-DC98-4AAC-8358-C77B98C75630@nokia.com>
To: public-webapps <public-webapps@w3.org>

The minutes from the August 14 Widgets voice conference are available  
at the following and copied below:


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

-Regards, Art Barstow


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

                                - DRAFT -

              Web Applications Working Group Teleconference

14 Aug 2008


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

    See also: [3]IRC log

       [3] http://www.w3.org/2008/08/14-wam-irc


           Art, Arve, Marcos, Mike, Nick

           Thomas, Claudio, Luca, Benoit, DavidR, Mark




      * [4]Topics
          1. [5]Agenda Review
          2. [6]OMTP Input
          3. [7]Turin f2f Agenda
          4. [8]Comments from MWBP WG on Requirements LC doc
          5. [9]"General Comments"
          6. [10]R16 Vistual Rendering Dimensions
          7. [11]MWBP References
          8. [12]Proposed requirement for "Resource Declarations"
          9. [13]R36 Open Default System Web Browser
         10. [14]New Req: User-Agent Header
         11. [15]New Requirement for User-Agent-Profile Header
         12. [16]New Requirement Accept Header
         13. [17]New Requirement: Default Use of Runtime Environemnet
             Configured Proxy
      * [18]Summary of Action Items

    <trackbot> Date: 14 August 2008

    <scribe> Meeting: Widgets Voice Conference

    Date: 14 August 2008

    <scribe> Scribe: Art

    <scribe> ScribeNick: ArtB

Agenda Review

    AB: any change requests?


OMTP Input

    AB: we need to get clarity on the contributors for OMTP's inputs
    before we can act on them
    ... any questions or concerns?

    Nick: by contributors do you mean companies?

    AB: yes I mean companies

Turin f2f Agenda

    AB: posted an update of the Turin f2f agenda
    ... [19]http://www.w3.org/2006/appformats/group/TurinF2F
    ... any comments?

      [19] http://www.w3.org/2006/appformats/group/TurinF2F


Comments from MWBP WG on Requirements LC doc

    AB: comments
    ... 5 new reqs proposed
    ... and changes for R16 and R36
    ... unfortunately Bryan isn't here
    ... there are three thread now Marcos?

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

    MC: yes

"General Comments"

    MC: we've talked about the ontologies before in the context of
    device capabilities
    ... our general consensus in the past is this type of tech is too
    complicated and not baked enough for v1.0

    Arve: yes I agree with Marcos

    AB: Mike and Nick?

    Mike: I would like to hear from Nick about use cases and market

    Nick: we do have device cap type stuff in progress in BONDI
    ... it is an important topic

    <marcos> +q

    <Zakim> MikeSmith, you wanted to saymight be good to hear Nick's
    opinion on this

    Nick: we are split on DCCI and simpler API based solutions

    AB: I agree with Marcos' statements

    Arve: device capability is too complicated for v1.0; also think this
    issue will be less important as platforms more powerful
    ... Widgets are NOT just for mobile
    ... For example, we ship Widgets for the desktop
    ... Thus I don't think DCCI, MWBP, etc. are relevant for a Core
    Widgets spec
    ... If any mobile specific work needs to be done, it should be in a
    separate spec
    ... or as extensions

    <marcos> MC: I agree with Arve

    AB: I agree with Arve's comments, pretty much 100%

R16 Vistual Rendering Dimensions

    AB: what are your thoughts on this Marcos?

    MC: I don't think they understand what the req says
    ... We don't expect "straight up" pixels

MWBP References

    AB: the comments suggest two refs from the MWBP WG should be added

    MC: I added the references in the Informative Ref section

    AB: OK to me
    ... any other comments?


Proposed requirement for "Resource Declarations"

    MC: I submitted some comments
    ... I would reject this requirement

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

    Arve: I pretty much agree with Marcos
    ... in that it is not possible to know if a widget will be a good or
    bad match for things like CPU or memory

    <marcos> MC: the widget engine might not be good... but the widget
    might be ok

    Arve: for example can't say apriori anything about battery life
    ... This requirement could be satisified via a security model

    AB: has Bryan responded to your feedback Marcos?

    MC: not yet and it's been almost one week

    <scribe> ACTION: Barstow make sure all newbies in the WG understand
    our working mode regarding comments and responses [recorded in

    <trackbot> Created ACTION-23 - Make sure all newbies in the WG
    understand our working mode regarding comments and responses [on
    Arthur Barstow - due 2008-08-21].

    Mike: when responding formally to a comment it is always a good idea
    to include a deadline for responses

    AB: that's an excellent point!

    Mike: regarding the timeline, a week is typically the best; 2 weeks
    if really needed
    ... want to eliminate chasing-up commentors if possible
    ... this will save time for everyone

    AB: so in the abscence of pushback from Bryan and/or BP WG, that
    proposed Resource Declaration req will not be added

R36 Open Default System Web Browser

    MC: I proposed some alternate text

    AB: any feedback on Marcos' proposed text?
    ... it's OK with me
    ... any other feedback?


New Req: User-Agent Header

    MC: I'm OK with including this

    AB: how would this req be manifested in a spec?

    MC: good question; I think it would just be a recommendation
    ... that is a recommendation for the UA

    Arve: setting this depends on the request itself
    ... what about loading external resources

    MC: what happens now or what is proposed in HTML5?

    Arve: HTML5 may not say anything about the UA header
    ... I also don't quite understand how this req would be specified

    Mike: seems like this falls into recommendations for UA behavior
    ... not sure we want to set a precedence for this
    ... it's a slippery slope for other UA behavior
    ... may want to say we don't want to define UA behavior at all

    AB: I agree with Mike concerns
    ... OTOH, I think that type of doc is useful
    ... Is this something that would be more appropriate for the MWBP's
    Web Apps recommendation?

    <Zakim> MikeSmith, you wanted to say that including spec language to
    address this type of UA behavior might be a slippery slope

    MC: I read the Web Apps doc from the MWBP WG and it is for
    developers not implemtors

    AB: I don't see a match between these 3 reqs and the set of specs we
    are working on
    ... I'm not opposed to adding these to an informative set of
    ... for UA implementors

    Arve: I'd like to see some Use Cases for these headers

    MC: to me setting the UA header is typically self-evident

    Arve: the problem with the UA header is that it isn't authoritative
    ... in that anyone can set it to anything thus I question its

    MC: so is it in or out

    AB: I think it is more in scope for a WG focusing on mobile specific
    ... Nick, Mike?

    <Zakim> MikeSmith, you wanted to say the MBWG is not chartered to
    produce specs that give normative conformance criteria for UAs

    Nick: no input now

    Mike: I think we're better off not including it
    ... the MWBP is not chartered for creating Normative specs for UAs
    ... Perhaps it could be a recommendation in BP v2.0 or something
    like that
    ... Agree it shouldn't be addressed in the Widgets spec

    AB: Propose we not add a requirement for User-Agent header
    ... any objections?

    Arve: no

    Marcos: no

    Mike: no

    Nick: no

    RESOLUTION: User Agent header will not be added to the Requirements

New Requirement for User-Agent-Profile Header

    AB: where is this header specified, Normatively?

    MC: the CC/PP spec

    <marcos> [23]http://www.w3.org/TR/NOTE-CCPPexchange

      [23] http://www.w3.org/TR/NOTE-CCPPexchange

    AB: the NOTE reference is Informative
    ... The W3C has produced a Recommendation for CC/PP and if we use
    anything, we should use it

    <arve> [24]http://www.w3.org/TR/NOTE-CCPP/

      [24] http://www.w3.org/TR/NOTE-CCPP/

    <arve> [25]http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/

      [25] http://www.w3.org/TR/2007/WD-CCPP-struct-vocab2-20070430/

    <marcos> [26]http://www.w3.org/TR/CCPP-struct-vocab/

      [26] http://www.w3.org/TR/CCPP-struct-vocab/

    AB: yes, that's it Marcos
    ... does this S&V spec define this header?

    Arve: no, I don't think so
    ... My main concern is that it adds bloat for each request without
    providing much value
    ... I don't think this is in widespread use

    <MikeSmith> amen to what arve just said

    MC: I agree

    Arve: some of the properties simply are not useful

    AB: Mike, Nick, any comments on this?

    Mike: I agree with Arve

    Nick: nothing to add

    AB: I tend to agree with Arve as wll
    ... Propose we do not add the U-A-Profile header to the Requirements
    ... any objections?

    Marcos: no

    Arve: no

    Mike: no

    Nick: no

    RESOLUTION: We will not add the User-Agent-Profile header

New Requirement Accept Header

    MC: when a UA makes a request, it should use the Accept header
    ... Again, I think it should be a recommendation (like the UA

    Arve: UAs already do this
    ... Every widget engine will build on a browser engine and support
    for this header will just be done
    ... Don't think we need to explicitly add it

    AB: what would we add to our specs to satisfy this req?

    Marcos: we wouldn't do anything

    Arve: agree
    ... leave this to HTML5 for example

    AB: Mike, Nick, any comments?

    Mike: I agree with Arve and Marcos; this should be left to HTML5
    ... IF it needs to be addressed at all

    Nick: agree with Mike

    AB: propose we not add the Accept header as an explicit requirement
    ... Any objections?


    RESOLUTION: we will not add the Accept header as an explicit

New Requirement: Default Use of Runtime Environemnet Configured Proxy

    MC: we already have a proxy support requirement
    ... Bryan read an older version that was updated based on feedback
    from Josh

    Arve: what is the impact on our specs?

    Marcos: I think it could be related to our security model but I'm
    not sure
    ... I did add the rationale

    Arve: not sure where we actually address this requirement

    AB: which requirement is related?

    MC: #39 [27]http://dev.w3.org/2006/waf/widgets-reqs/#r39.-

      [27] http://dev.w3.org/2006/waf/widgets-reqs/#r39.-

    AB: Arve, do you have problems with #39 as currently specified in
    the LC doc?

    <marcos> [28]http://dev.w3.org/2006/waf/widgets-reqs/#r41.-

      [28] http://dev.w3.org/2006/waf/widgets-reqs/#r41.-

    <marcos> sorry

    Arve: in practice all implementations must support this req
    ... Proxy support will be required
    ... But it's not going to affect interop
    ... It doesn't affect how the widget will be written

    Marcos: I agree; this is an implemenation detail
    ... would like to hear about the security aspects

    Nick: I agree need to separate security concerns

    Mike: I agree with Marcos re this is an implemenation detail that we
    don't need to specifiy

    AB: propse we not add this requirement
    ... Any objections?


    RESOLUTION: the new requirement for proxies will not be added

    AB: Meeting Ended

Summary of Action Items

    [NEW] ACTION: Barstow make sure all newbies in the WG understand our
    working mode regarding comments and responses [recorded in

    [End of minutes]
Received on Thursday, 14 August 2008 13:22:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:47 UTC