The minutes from the August 26 Widgets f2f meeting are available at the following and copied below:

 <http://www.w3.org/2008/08/26-wam-minutes.html>

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

-Regards, Art Barstow


   [1]W3C

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

                               - DRAFT -

                          Widgets F2F Meeting
                              26 Aug 2008

   [2]Agenda

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

   See also: [3]IRC log

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

Attendees

   Present
          Art_Barstow, Marcos_Caceres, Mark_Priestly, David_Rogers,
          Fabio_Ricciato, Luca_Bruera, Benoit_Suzzane, Marco_Bartolini,
          Maruo_Sacco, Paddy_Byers, Thomas_Landspurg, Claudio_Venezia,
          Josh_Soref, Arve_Bersvendsen, Nick_Allot

   Regrets
   Chair
          Art

   Scribe
          Art

Contents

     * [4]Topics
         1. [5]Introduction
         2. [6]Agenda Review
         3. [7]Last Call of Requirements Doc
         4. [8]Disposition of Comments document for the Requirement
            Last Call
         5. [9]Configuration and Packing Spec
         6. [10]ZIP Archive
         7. [11]Issue #16 - Do widgets need their own URI scheme?
         8. [12]URI Scheme and Query parameter
         9. [13]URI Scheme and Encoding
        10. [14]P&C Issues
        11. [15]Issue #34 - What happens when one runs out of storage
            space when decompressing a widget?
        12. [16]Issue #46 - Need to define a <span> for i18n purposes
            in configuration document
        13. [17]Issue #20 - Current <content> model does not allow
            multiple views
        14. [18]Issue #21 - should Widgets 1.0 allow fallback for
            <content> element?
        15. [19]Webwag presentation
     * [20]Summary of Action Items
     _________________________________________________________


   Date: 26 August 2008

   <scribe> Scribe: Art

   <scribe> ScribeNick: ArtB

Introduction

   <claudio> Fabio Ricciato

Agenda Review

   <MikeSmith> ArtB: if you have the phone set up, can you please call
   1.617.761.6200 with code 26632 ?

   AB: any change requests for the agenda

   Josh: I won't be here on Thursday

   Arve: I need to leave early Thursday
   ... want to push APIs to Wednesday

   AB: any other change requests?

   [None]

Last Call of Requirements Doc

   AB: anything from Kryztof we want to discuss?

   MC: no; I will respond to his comments by end of next week

   AB: I18N is done, right?

   MC: yes

   AB: Josh submitted some comments at the end of last week

   MC: yes mostly editorial comments but 1-2 issues

   AB: Josh submitted two e-mails:
   ... 1.
   [21]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/04
   50.html
   ... 2.
   [22]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/04
   51.html
   ... one issue is about proxies and we already identified that as an
   issue (#17)

[21] http://lists.w3.org/Archives/Public/public-webapps/ 2008JulSep/0450.html [22] http://lists.w3.org/Archives/Public/public-webapps/ 2008JulSep/0451.html

   MC: we decided the proxy used by an instance of a widget is an impl
   detail

   JS: there is also an issue about the proxy and a signature

   ABe: but we are signing the uncompressed files
   ... agree proxy is an implemenation detail

   MC: we removed the requirement an end user can specify the proxy
   ... since that is an implementation detail

   BS: so what will the spec say?

   MC: we no longer have a related requirement
   ... We could have an informative note about it
   ... we are saying that if a Widget instance wants to use a specific
   proxy that's OK but we don't need our spec to saying anything
   Normative about this

   AB: proposed Resolution: Issue #17 is Closed - this is an
   implementation detail for Widget User Agents; we may add an
   Informative note in one of the specs
   ... any objections?

   <arve> none

   [None]

   RESOLUTION: Issue #17 is Closed - this is an implementation detail
   for Widget User Agents; we may add an Informative note in one of the
   specs

   <scribe> ACTION: Barstow close Issue #17 [recorded in
   [23]http://www.w3.org/2008/08/26-wam-minutes.html#action01]

   <trackbot> Created ACTION-218 - Close Issue #17 [on Arthur Barstow -
   due 2008-09-02].

   AB: are there any other comments in Josh's first email we want to
   discuss?

   JS: no; but let's look at my 2nd email

   <timeless> R40. Automatic Updates

   <timeless> what happens if i have 3 instances of a widget? do they
   all get upgraded?

   JS: the other issue is what happens when 3 instances of one widget
   are installed - what happens during auto-update?

   <Benoit> they should...

   ABe: I think this should be an impl detail

   MC: I think all 3 should get updated

   ABe: I don't think we should be overly prescriptive here
   ... don't want to have to add a bunch of APIs to support this

   JS: < reads Req #40 >

   MC: I think we need to be flexible here

   BS: could say the user should be able to check (when there are
   multiple instances installed)

   AB: there is also the scenario of a device having more than one
   Widget UA

   <arve> ABe: Could we add an informative note that a UA MAY treat two
   installations of a widget from a source URI as either two different
   widgets, or as two instances of one widget

   AB: propose new Issue: should text about auto-updates regarding
   multiple instances of installed widgets be Informative or Normative?
   ... anyone object to this issue being addressed by Informative text?

   MC: I object
   ... I don't think we should mention it at this point
   ... if Benoit or someone else provides some text, I can add it to
   the auto updates spec

   <Benoit> ok to take it out

   AB: propose Resolution: the reqs doc will be silent on auto-updates
   and multiple instances
   ... any disagreements

   [none]

   RESOLUTION: the reqs doc will be silent on auto-updates and multiple
   instances (but some Informative text may be added to the auto-update
   spec)

   AB: any other comments Josh?

   JS: not to discuss now

   MC: Marcos, can you commit to responding to Josh's two email by the
   end of next week?
   ... yes

   <scribe> ACTION: Marcos respond to Josh Soref's two e-mail comments
   by Sept 5 [recorded in
   [24]http://www.w3.org/2008/08/26-wam-minutes.html#action02]

   <trackbot> Created ACTION-219 - Respond to Josh Soref's two e-mail
   comments by Sept 5 [on Marcos Caceres - due 2008-09-02].

Disposition of Comments document for the Requirement Last Call

   AB:
   [25]http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-r
   eqs-20080625
   ... unfortunately this is a Member-only link
   ... I don't like this

[25] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-reqs-20080625

   MC: it's because some of the WG's responses could include
   Member-confidential info

   AB: what's the status?

   MC: it contains everything but: 1) Krzystof's comments; 2) Josh'
   latest two e-mails

   AB: good

   MC: re issue LC-1983 from Josh, Issue #1 is "should we mandate that
   developers and admins be allowed to

   install their own certs?"

   MP: this is related to req #38
   ... I submitted some comments about this to the mail list
   ... and proposed new text

   AB: has this been addressed in the Editor's Draft?

   MC: no; waiting for more input

   ABe: I think the most we can specify here is a MAY

   MC: this can be viewed as in impl detail of the Widget UA

   MP: I agree it should be impl-specific

   <timeless> propose Could the digital signature specification have an
   informative note that widget authors should not expect to be able to
   sign widgets using certificates which are not chained to well known
   public roots.

   MP: but we don't want it to break the security model
   ... If the requirement was removed from the Reqs doc that is OK
   ... from VF's perspective, we could remove it

   MC: I propose "Additional Digital Certificates" (Issue #38 in the LC
   doc) be removed from the Reqs and it becomes an Informative note in
   the DigSig spec

   AB: any comments or objections to Marcos' proposal?

   [None]

   RESOLUTION: Additional Digital Certificates" (Issue #38 in the LC
   doc) be removed from the Reqs and it becomes an Informative note in
   the DigSig spec

   AB: what about the comments submitted by Frederick Hirsch (Chair of
   the XML Security WG) submitted on August 25?

   MC: we have already addressed his comments
   ... they were both Editorial
   ... I will add his comments to the LC Disposition of Comments doc

   AB: with the possible exception of Krzystof's comments and our
   responses raising some new Issues, I think we're mostly OK with the
   comments we received re the LC Reqs doc

   MC: I will need to address the URI and IRI references correctly
   ... it would be good to get a URI expert to review my changes

   AB: any other comments we need to discuss?

   MC: some of Krzystof's comments are a bit academic
   ... but again, I will respond to all of his comments

Configuration and Packing Spec

   <barstow> AB: we have Issues identified in the Editor's Draft

   <barstow> ... as well as Issues defined in our Action and Issue DB
   [26]http://www.w3.org/2008/webapps/track/

     [26] http://www.w3.org/2008/webapps/track/

   <barstow> ... Marcos, what is your preference for reviewing these
   issues?

   <barstow> MC: let's first look at the issues in the latest ED

   <barstow> ... I made an update during my flight from Brisbane

   <barstow> ... I will upload it now ...

   <barstow> AB: latest Editor's Draft is
   [27]http://dev.w3.org/2006/waf/widgets/

     [27] http://dev.w3.org/2006/waf/widgets/

ZIP Archive

   <barstow> MC: we are restricted to the limits of ZIP as implemented
   and deployed today

   <barstow> ... UTF-8 now supported in ZIP format

   <barstow> ... can also now explicitly add an encoding

   <barstow> MC: a question for us - which version of ZIP do we want to
   support?

   <claudio> is conference 26632 expired? I cannot dial in...

   <MikeSmith> claudio: yeah

   <barstow> ... supporting the latest version of ZIP could add some
   additional problems and/or complexity

   <MikeSmith> claudio: please use 26631

   <barstow> MC: the motion is "we only support UTF-8 encoded file
   names"

   <claudio> ok we're in

   <barstow> AB: what happens if we make this a firm requirement
   regading existing impls?

   <barstow> MC: I think Apple will fail

   <barstow> ... when Dashboard widget is un-zipped on a Windows system

   <barstow> MC: we don't have to add other encoding now; they can be
   added later i.e. in a subsequent version of the spec

   <barstow> ABe: I think what we have currently spec'ed is OK

   <barstow> AB: version of ZIP do we now support is what, Marcos?

   <barstow> MC: 6.3

   <barstow> ABe: frankly, we need an open spec for ZIP

   <barstow> ... we shouldn't be blocked by PKWare

   <barstow> MC: ISO is working on such a spec now

   <Ralph> you folks have two teleconferences running and 1 person on
   each

   <Ralph> I will attempt to move the person on the first teleconf to
   here

   <barstow> MC: the motion is "UTF-8 and CP437" support

   <barstow> MC: the I18N WG recommended this change

   <barstow> ...
   <[28]http://www.w3.org/mid/4D25F22093241741BC1D0EEBC2DBB1DA014A3C1A6
   [EMAIL PROTECTED]>

[28] http://www.w3.org/mid/ [EMAIL PROTECTED]

   <barstow> MC: I propose step #8 of the ZIP Archive Verification step
   be left as is and we would not accept the change proposed by the
   I18N WG

   <barstow> AB: any objections to Marcos' propsosal?

   <barstow> [None]

   <barstow> RESOLUTION: step #8 of the ZIP Archive Verification step
   be left as is and we would not accept the change proposed by the
   I18N WG

   <barstow> JS: should we explain why?

   <barstow> MC: I already stated rationale in my response to Addison:
   <[29]http://www.w3.org/mid/b21a10670808122128u4a8fac1erebd1f5d7cf908
   [EMAIL PROTECTED]>

[29] http://www.w3.org/mid/ [EMAIL PROTECTED]

Issue #16 - Do widgets need their own URI scheme?

   <barstow> AB: issue is:
   [30]http://www.w3.org/2008/webapps/track/issues/16

     [30] http://www.w3.org/2008/webapps/track/issues/16

   <barstow> MC: Tim Berners-Lee and some other members of the TAG have
   suggested we use http: scheme

   <barstow> ... and we should not mint/create a new scheme

   <barstow> MC: the UUID part of the grammar is a "straw man"

   <barstow> TL: why not use a relative path?

   <barstow> MC: in the DOM must have an absolute path

   <barstow> TL: but an author of a Widget just needs to know relative
   path

   <barstow> JS: but on different platforms, relative paths could be
   treated differently

   <barstow> MC: widget developers are heavily discouraged from ever
   using absolute URIs

   <barstow> ABe: the author can't predict the domain part of the URI
   (expect some type of UUID)

   <barstow> AB: besides Tim, Stuart Williams and Roy Fielding (also on
   the TAG) also raised some concerns about the widgets: scheme

   <barstow> ... Roy:
   [31]http://lists.w3.org/Archives/Public/www-tag/2008Aug/0066.html

     [31] http://lists.w3.org/Archives/Public/www-tag/2008Aug/0066.html

   <barstow> AB: regarding the process, when the spec is ready to go to
   Candidate, if this issue is still Open, we will need to convince W3C
   Management the WG made the right decision to ignore this feedback

   <barstow> MC: query strings are another part of the scheme that is
   an open issue

   <barstow> MC: do we want to support POST?

   <barstow> MC: I think Roy is over complicating the issue

   <barstow> JS: Roy recommends "cid" scheme

   <barstow> ... has anyone looked at it?

   <barstow> ... At a minimum, we should look at it and respond

   <barstow> JS: If you look at Roy's first statement, I think he's
   wrong.

   <barstow> AB: perhaps he doesn't clearly understand our use case;
   seems like he is thinking about "web widgets"

   <barstow> MC: our use case is taking files and put them in a ZIP

   <barstow> TL: not sure it's good to make a differentiation between
   WebApps Widgets and "Web Widgets"

   <barstow> MC: our approach is that a single file is transferred and
   transfer can come over Bluetooth, Infra-red, etc. but it doesn't
   necessarily need to be HTTP

   <barstow> ABe: I agree there may be some work we can do to better
   define our use case

   <barstow> TL: why not use "file"?

   <barstow> JS: because file: has some issues e.g. security

   <barstow> ABe: Widget authors could easily abuse file: and do some
   very bad things

   <barstow> MC: the widget: scheme is supposed to create a sandbox

   <barstow> TL: so we just want the Widget to only be able to access
   its own resources

   <barstow> JS: cid: doesn't appear to be appropriate

   <barstow> ... because it requires MIME support

   <timeless> [32]http://www.w3.org/Addressing/URL/4_1_Cid.html

     [32] http://www.w3.org/Addressing/URL/4_1_Cid.html

   <barstow> NA: the widgets scheme gives a security box, right?

   <barstow> MC: yes, but some privacy too

   <barstow> JS: the Widget UA needs to be able to expose to the Widget
   a unique resource that is related to itself (and nothing else)

   <barstow> [We pause and look at R6:
   [33]http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing
   Addressing Scheme and then continue discussion]

     [33] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing

   <barstow> JS: perhaps the requirement needs some additional text re
   uniqueness

   <barstow> NA: I think there are some security aspects of the widget:
   scheme that are implied and perhaps should be more explicit

   <barstow> ... perhaps the use cases need to be expanded

   <claudio>
   [34]http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/03
   28.html

[34] http://lists.w3.org/Archives/Public/public-webapps/ 2008JulSep/0328.html

   <barstow> CV: Stuart Williams asked for additional use case
   information

   <barstow> CV: Stuart also asked about widget to widget communication

   <barstow> MC: HTML5 is addressing document to document communication
   and presumably Widgets could leverage that mechanism

   <barstow> ABe: I think using our own widget: scheme will help reduce
   security risks

   <barstow> AB: so where does this leave us?

   <barstow> MC: we need to clarify the model; it is based on the "old
   timers" in the WG

   <barstow> ... I can clarify the text and address any ambiguities

   <barstow> MC: we will have to continue discussions with the TAG

   <barstow> ... I suspect they may have not actually read our spec
   thoroughly and don't understand our use cases

   <barstow> BS: perhaps we can invite them to one of our voice confs

   <barstow> AB: we can meet with them f2f in Mandelieu

   <barstow> MC: I think we are doing the right thing and agree we need
   to continue to engage with them

   <barstow> AB: I can invite Stuart and the TAG to one of our voice
   confs

   <barstow> ... I think it would be helpful to first expand on our Use
   cases and Rationale

   <barstow> TL: still think the distinction between Widgets and Web
   Widgets is causing confusing

   <barstow> ABe: don't think of Widgets as web pages but a collection
   of resources that can be packaged and installed

   <barstow> MC: I think the Web widget model and Webwag widgets are a
   different model; perhaps we'll get there in v2

   <barstow> ABe: the widget: scheme will allow browsers to reuse their
   security model (sandbox)

   <barstow> ACTION: soref respond to Roy Fielding's email regarding
   the widget scheme and his proposal to use cid: [recorded in
   [35]http://www.w3.org/2008/08/26-wam-minutes.html#action03]

   <trackbot> Created ACTION-220 - Respond to Roy Fielding's email
   regarding the widget scheme and his proposal to use cid: [on Josh
   Soref - due 2008-09-02].

   <barstow> AB: do we need more motivational text?

   <barstow> MC: I think we have already responded well enough

   <barstow> ... I don't think the requirement needs to be updated

   <barstow> AB: do you want me to invite Stuart and/or the TAG to our
   voice conf?

   <barstow> MC: not yet; let

   <barstow> ... us wait until Roy responds to Josh's e-mail

URI Scheme and Query parameter

   <marcos> [36]http://dev.w3.org/2006/waf/widgets/Overview.src.html

     [36] http://dev.w3.org/2006/waf/widgets/Overview.src.html

   <barstow> [ the network is not capable of delivering the entire
   Editor Draft of the latest P&C spec thus I cannot add the text
   Marcos created re the URI query ... ]

   <marcos> MC: how do we resolve: <content src="index#1.html?foo=bar">
   ?

   <barstow> AB: does this need to addressed for v1?

   <barstow> MC: yes, I think so

   <barstow> ABe: I think the example is a bit of an edge case

   <barstow> AB: if we say query strings aren't allowed, what breaks?

   <barstow> ABe: I tried your example in a couple of different
   browsers and they yield different results

   <barstow> ... The question isn't about forbid vs. not forbid, but if
   query string should be supported

   <barstow> MC: once we hit the "#" we don't say what happens

   <barstow> ABe: one of the two user agents I tried has a bug; we
   should clarify in the spec

   <barstow> MC: we should just say the value of the src attr is a URI
   reference

   <barstow> ... I will also need to update the definition of the IRI
   attribute

   <barstow> [ Marcos adds text to his latest ED that describes the
   results of our discussion: we don't chop stuff off the end but we
   don't interpret it either ]

URI Scheme and Encoding

   <barstow> MC: need to add text about the encoding

   <barstow> ABe: I would expect a UA to map any CP437 chars to UTF-8

   <barstow> ABe: we could say anything outside of US-ASCII must be
   UTF-8

   <scribe> Scribe: Art

   <scribe> ScribeNick: ArtB

P&C Issues

   AB: agenda: [37]http://www.w3.org/2006/appformats/group/TurinF2F
   ... I'm indifferent as to the order we discuss the issues

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

Issue #34 - What happens when one runs out of storage space when
decompressing a widget?

   AB: issue #34 - [38]http://www.w3.org/2008/webapps/track/issues/34

     [38] http://www.w3.org/2008/webapps/track/issues/34

   MC: we discussed this in IRC a week or two ago
   ... we being me and Arve

   ABe: I think this is an impl detail and a fatal error

   JS: I want this to be a fatal error
   ... I don't think a UA should limp along
   ... if it can't handle all of the files

   ABe: if a UA canNOT represent all resources in the package, it must
   be a fatal error

   JS: a UA could tell the user if there aren't enough resources and
   ask them to remove/stop something

   AB: I'm not convinced we need to address this question

   JS: there is no guarantee the user can be given a message before it
   dies

   AB: what would we need to specify and in what spec would we address
   this?

   MC: we could say something in the P&C spec but probably nothing
   normative
   ... in the extraction phase, the Widget UA should stop the widget
   ... if there is a storage failure

   AB: does anyone think this issue is important enough to submit an
   input to address the issue?

   [None]

   AB: I propose we close this issue and say we will consider it for v2
   ... any objections?

   ABe: I don't think this issue should be handled by a spec
   ... but could be covered in some type of informational doc

   RESOLUTION: we will close this issue for now (not critical) and we
   may consider it in the future

   <scribe> ACTION: Barstow close Issue #34 with resolution above
   [recorded in
   [39]http://www.w3.org/2008/08/26-wam-minutes.html#action04]

   <trackbot> Created ACTION-221 - Close Issue #34 with resolution
   above [on Arthur Barstow - due 2008-09-02].

Issue #46 - Need to define a <span> for i18n purposes in configuration
document

   AB: issue is [40]http://www.w3.org/2008/webapps/track/issues/46

     [40] http://www.w3.org/2008/webapps/track/issues/46

   MC: the issue is that part of the widget should be author-able with
   Right-to-Left and other parts Left-to-Right
   ... the proposal is a <span> element like the one in HTML

   ABe: so this would mean the description element can support more
   than one span element?

   AB: do any web browsers support this requirement?

   MC: yes

   ABe: how do I handle different descriptions?

   MC: put each description in a different file

   ABe: what attributes would be placed on <span>

   MC: probably just direction

   BS: why do we need <span> if localized text is placed in localized
   folders

   MC: because authors may want to use both directions in a single
   description

   AB: Marcos, you will spec the span element with just the one
   direction element?

   MC: yes; plus need to change the parsing model

   AB: I'm wondering about the burden to the UA

   Marcos: ask I18N WG if Unicode RTL is sufficiently supported in UAs;
   if not we will include the <span> element in the Widgets spec

   JS: HTML5 has a <bdo> element we should consider

   ABe: I think we need some more solid research

Issue #20 - Current <content> model does not allow multiple views

   AB: issue is: [41]http://www.w3.org/2008/webapps/track/issues/20

     [41] http://www.w3.org/2008/webapps/track/issues/20

   [ Marcos demonstrates the issue by showing a Dashboard Clock widget
   as one instance and the Digital Clock "text" at the top tool bar ]

   PB: in Java can have one application that has two different running
   instances - each with a different view e.g. presenation

   MC: in the mobile world a single clock widget could take up the
   entire screen or just be a small piece on the idle screen

   ABe: I don't want to have multiple content elements but perhaps
   provide APIs to control views

   JS: on S60 the idle screen apps cannot accept any input so they
   aren't really views in this context
   ... an app can change modes e.g. full to small
   ... icons and notifications are covered elsewhere
   ... I think the answer to "can we have multiple <content> elements?"
   is no

   BS: we need a way to suppport two different views but those two
   views do not need to be displayable at the same time
   ... I think that can be done with APIs rather than <content>
   elements

   ABe: we support rendering widgets in different "modes"
   ... with or without chrome and full screen and "dock mode"
   ... a problem with multiple content elements is how the instances
   communicate with each other

   AB: I propose we close this issue now and put it in on the "consider
   for v2 list"

   MC: I agree with that

   AB: any objections?

   [None]

   RESOLUTION: Issue #20 will be closed and this feature will be added
   to the v2 Feature List

   <scribe> ACTION: Barstow close Issue #20 with the resolution above
   [recorded in
   [42]http://www.w3.org/2008/08/26-wam-minutes.html#action05]

   <trackbot> Created ACTION-222 - Close Issue #20 with the resolution
   above [on Arthur Barstow - due 2008-09-02].

Issue #21 - should Widgets 1.0 allow fallback for <content> element?

   AB: issue is: [43]http://www.w3.org/2008/webapps/track/issues/21

     [43] http://www.w3.org/2008/webapps/track/issues/21

   MC: some vendors have requested this feature

   ABe: technically speaking, I don't think this is difficult to
   implement
   ... but I do think some vendors with proprietary HTML extensions
   won't work very well
   ... I think this could be abused to make the default be an "upgrade
   here" message

   CV: is this the same question as what a UA should do if an API isn't
   supported?

   MC: no, I see it as different but related

   BS: can we push this to v2?

   MC: unless some vendor says it is mandatory for v1, I think we can
   push it to v2

   AB: propose closing Issue #21 and add it to the v2 Feature List
   ... any objections?

   [None]

   RESOLUTION: Issue #21 is closed and will be added to the v2 Feature
   List

   <scribe> ACTION: Barstow close Issue #21 with the resolution above
   [recorded in
   [44]http://www.w3.org/2008/08/26-wam-minutes.html#action06]

   <trackbot> Created ACTION-223 - Close Issue #21 with the resolution
   above [on Arthur Barstow - due 2008-09-02].

Webwag presentation

   <claudio> mission: providing means for accessing digital contents
   from everywhere via mobile

   <claudio> WW definition of widget synthesize in single view lots of
   info

   <claudio> WW is multiplatform, multidevice

   <claudio> WW philosophy about Widget multidevice support: "smooth
   porting" rather than "write once/run everywhere"

   <claudio> WW would like to support W3C spec as far as possible

   <claudio> MC: will widgets be bound to server side for long time?

   <claudio> WW: the installed widget mode might not scale...

   <claudio> MC: deciding the balance between client and server is up
   to Widget implementors

   <claudio> Arve: installed widget are more reliable in terms of
   security (signature)

   AB: Meeting Closed

Summary of Action Items

   [NEW] ACTION: Barstow close Issue #17 [recorded in
   [45]http://www.w3.org/2008/08/26-wam-minutes.html#action01]
   [NEW] ACTION: Barstow close Issue #20 with the resolution above
   [recorded in
   [46]http://www.w3.org/2008/08/26-wam-minutes.html#action05]
   [NEW] ACTION: Barstow close Issue #21 with the resolution above
   [recorded in
   [47]http://www.w3.org/2008/08/26-wam-minutes.html#action06]
   [NEW] ACTION: Barstow close Issue #34 with resolution above
   [recorded in
   [48]http://www.w3.org/2008/08/26-wam-minutes.html#action04]
   [NEW] ACTION: Marcos respond to Josh Soref's two e-mail comments by
   Sept 5 [recorded in
   [49]http://www.w3.org/2008/08/26-wam-minutes.html#action02]
   [NEW] ACTION: soref respond to Roy Fielding's email regarding the
   widget scheme and his proposal to use cid: [recorded in
   [50]http://www.w3.org/2008/08/26-wam-minutes.html#action03]

   [End of minutes]



Reply via email to