Widgets f2f Meeting -- 20 Oct 2008

<timeless> that reminds me, i should d/l the maps + favorite the addresses

<abarsto> Date: 20 October 2008

<abarsto> Scribe: Art

<abarsto> ScribeNick: ArtB

<timeless> 10a. Can you invite zakim?

Introductions

<abarsto> [ round robin of Widgets people mostly ]

<abarsto> Fabrice: Orange/FT AC rep

Agenda review and tweaking

<abarsto> AB: agenda: http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda

<abarsto> AB: any changes or additions?

<abarsto> MP: what about OpenAjax's API style guide?

<abarsto> AB: how about I add it to AOB?

<abarsto> MP: OK

<abarsto> AB: I can also ask Chaals to let us know if/when he discusses it

Issue #46 - I18N

<abarsto> AB: what remains to be done with this issue?

<abarsto> MC: I have addressed this issue in the spec

<abarsto> ... The main issue is how to address LtoR and RtoL in the same piece of text

<abarsto> ... I added OPTIONAL support for the ITS' span element

<abarsto> ... If supported must support its:dir atrribute too

<abarsto> ... Not clear if we need to bind its:dir to widgets description or name element.

<abarsto> ... Thus I need to clarify with the I18N WG

<abarsto> ... This also means I needed to change our RELAXNG schema

<abarsto> AB: any recommendations on the its:dir binding issue?

<abarsto> ... It would be optional, right?

<abarsto> MC: yes, it would be optional

<abarsto> AB: OK, so we leave this open for now

<abarsto> ... and try to close it by the end of this meeting.

<abarsto> MC: If I can meet with Felix we can close this today

<abarsto> MS: yes, I can make that intro.

MC: this issue surfaces because ZIP encodes filename differently on different OS's e.g. Mac does it one way and Widows does something differentMS: if we are doing something differently from other specs i.e. the URI or IRI specs, I would be concernedAB: does this mean there is a hole in the IRI specMC: no; the problem is different OS's handling... we need to take care of these interop probsAB: action plan is what then?

[ MC demonstrates some of the interop issues ... ]

AB: what's the action plan?

MC: I need to implement what's spec'ed

AB: does this need to be done before LC?

MC: yes

AB: can anyone help Marcos?

[ No voluneeters :-( ]

BS: can someone here at the TPAC help?

MC: it's a bit ugly and nitty-gritty
... but I can do it
... Need to actually look at the ZIP files in hex

[ MC shows HexEdit example of a .zip file ]

<scribe> ScribeNick: ArtB

MC: if not utf8, use cp437
... I think Josh can help me

Section 5.4 Need validator's point of view

MC: this was raised by Dom
... I added some related text to the definitions
... Also need to reflect the view of a validator
... I don't think this is a high priority
... If someone wants to contribute, that would be good

AB: any volunteers for a conformance checker?
... perhaps we can some W3C staff/webreq help
... I'll check with Mike

<scribe> ACTION: Barstow see if the W3C systeam/webreq can help with a conformance checker [recorded in http://www.w3.org/2008/10/20-wam-minutes.html#action01]

<trackbot> Created ACTION-257 - See if the W3C systeam/webreq can help with a conformance checker [on Arthur Barstow - due 2008-10-27].

AB: I would imagine that type of service could be included in a Widget repository service

MC: something like this could be added to validator.nu

AB: this is Henri's service?

MC: yes, but just giving a schema isn't that helpful
... need to provide "hints" too
... I believe validator.nu is Open Source so we could roll our own service
... the note in Section 5.4 has been removed since I think its priority is too low

Section 5.5 Need for a MIME type

AB: http://dev.w3.org/2006/waf/widgets/#mime-type
... a potential sub-issue here is Security Concerns
... I would expect IANA to have a template for what's required
... RFC 4289 defines the process

[ We spend some type looking at the W3C/IANA MIME registration procedures ]

AB: do we need to complete the template?
... We can check the precedence
... a question I have is if we need to complete the template before we publish a LC doc

Version String in Section 6.14

AB: http://dev.w3.org/2006/waf/widgets/#the-version (now in section 6.15)
... what are you looking for?

MC: that should not be there
... this should be in the update spec, not P&C

MP: if it is in the Update spec then where?

MC: in the update element

MP: if you want version info in the widget but won't have an update, what do you do?

PB: so version attribute on widget element remains?

MC: yes

AB: so the update element will have a verison attribute too?

MC: yes

<scribe> ACTION: Macros move the version string section from P&C spec to the Updates spec [recorded in http://www.w3.org/2008/10/20-wam-minutes.html#action02]

<trackbot> Sorry, couldn't find user - Macros

<scribe> ACTION: Marcos move the version string section from P&C spec to the Updates spec [recorded in http://www.w3.org/2008/10/20-wam-minutes.html#action03]

<trackbot> Created ACTION-260 - Move the version string section from P&C spec to the Updates spec [on Marcos Caceres - due 2008-10-27].

MC: there is another spec being written by David Orchard re template for attributes
... I have used text from URI Template (RFC working draft)

<scribe> ACTION: Barstow determine the status of URI Template RFC and report back to WG [recorded in http://www.w3.org/2008/10/20-wam-minutes.html#action04]

<trackbot> Created ACTION-261 - Determine the status of URI Template RFC and report back to WG [on Arthur Barstow - due 2008-10-27].

MC: another discussion we can have is the use of this template mechanism for other elements in the Updates spec

AB: do we need to consider its usage in the P&C spec?

MC: no
... we can use OMA's DL spec e.g. for status codes
... regarding the Update spec.

Section 7 Need to add cp437 text

AB: the agenda mentions this issue but I think it has now been addressed
... Is that right, Marcos?

MC: yes, consider this part of the URI/IRI proc model discussion we had earlier.

[ Take a Coffee Break ]

Section 8.2 - What do we do if run out of space?

AB: status Marcos?

MC: I removed this because it is an implementation issue
... Josh added this

ABe: I agree it is an implementation detail for the P&C spec
... also agree it is a real implemenation detail for an implemenation

MC: I changed related text http://dev.w3.org/2006/waf/widgets/#extracting

ABe: I think the new text is sufficient

AB: Josh, what do you think (you raised this issue)?

MC: I would expect an impl to use the ZIP header to determine the space needed and do the right thing

JS: this is OK with me

Section 8.2, Step #10 - How to handle SVG Icon Formats

AB: see http://dev.w3.org/2006/waf/widgets/#step-10
... what can we expect to do with this issue?

MC: we need feedback from implementors
... need to understand the interactivity e.g. if the SVG has some JavaScript

ABe: the JS could run outside of the widget
... We wouldn't be able to do anything about security in that case

MC: my feeling is we should drop SVG for v1
... and add it to v2

ABe: the problem that will introduce is that most operators will require SVG for icon formats

MP: yes, I believe that is true for us

JS: it's not just a graphics format (and static) but it can also be an app format i.e. actually running as the "main" widget

CV: we need to support SVG Tiny
... and 1.2 is preferred

MC: we have an open issue regarding 1.1 vs 1.2
... the issue is how to handle the events on the icon e.g. via XHR
... the question is do we allow that
... Will it introduce too much implementation burden

BS: think the most important requirement is the image format
... and interactivity is secondary importance
... I think the most common usage is static icon images

AB: any other comments?

MC: I think we should leave this as an impl detail
... it is optional to support SVG as an icon format

AB: if we do that, what interop probs will there be?

JS: could add a should for widget authors re SVG icon format

ABe: not sure about use of should; could be too strong
... perhaps should use MAY

MC: I've stopped using normative text regarding authoring reqs

JS: so it's more of a hint in this case?

MC: yes

ABe: we could remove the entire author req

MC: no, I disagree; want to keep it
... but those who want it will add; otherwise they won't

AB: are these "Author Requirements" non-normative?

MS: don't call them "Guidelines"
... perhaps they should be in a sep doc

JS: we could leave them in for now

MC: yes, they could be in a separate doc

AB: are these Autho Reqs normative or non-normative?

MC: I think they should be Normative

MS: If we are going to build a validator, they should be Normative
... are there constraints that cannot be expressed in a schema?

MC: yes, some of the ZIP constraints

MS: if you want these reqs to be in the validator, they should be Normative

MC: agree; DOM raised a similar issue
... perhaps the Author reqs should be changed to "Conformance Checker"

MS: that is what HTML5 does
... with some text to qualify relationship to authoring

MC: I can re-write all of the Author Reqs to Conformance Reqs and make them all Normative

AB: any objections?

[ None ]

JS: should we check with Hixie re HTML5?

MC: I talked to HTML5 this morning
... he is considering a script to move authoring stuff into a sep doc

JS: I'm OK with doing this way

MC: there is another issue
... this could be a problem if we add a new "Product"
... We would now have a 4th product.
... And the Conformance Checker can claim conformance to the spec

AB: can you do that?

MC: yes, I can do that
... let someone else create the Conformance Checker.

AB: any volunteers?

RESOLUTION: all of the Author requirements will be changed to Conformance Checker requirements and all of these requirements will be Normative.

LM: I don't recall seeing a good definition of Conformance Checker

MC: I hope that isn't a rat hole
... HTML5 attempts to make such a definition

MS: we could look at what has been done in HTML5

Section 8.2, Step #11 - Is additional security model needed here?

AB: http://dev.w3.org/2006/waf/widgets/#step-11
... what
... is the issue?

MC: this may be out of scope for this spec
... Not sure we need to go beyond what is specified

AB: what do people think?

PB: not sure what the security issue is

MC: need to spec how to put something on the screen and what we need to say about runtime requirements
... eg. if the widget tries to do something that raises a security exception
... What do we specify regarding instantiation e.g. security policies
... does HTML5 deal with this?

MS: the latest ED of HTMl5 doesn't say anything about rendering

MC: I could talk to Hixie

MS: we could ask for an Editor to draft some text

PB: within BONDI, we are interested in the security policy related to the instantiation

MC: we used to have a step #12 which tried to deal with this
... but it was remove because this is out of scope

AB: I'm OK with leaving step #11 as is
... any objections to deleting the security model issue from Step #11?

[ None ]

RESOLUTION: Step #11 of the P&C will not address the security model

ABe: I'm uncomfortable with separating the P&C spec from Security Model
... e.g. it could create some new authoring issues

MC: we do need to spec the security models
... expect BONDI to do some relevant work here that we may be able to use
... expect a separate policy doc from the config doc

MP: agree, we envision the policy doc as a separate from the config doc

MC: we could bind the config doc to the policy doc via the feature element

MP: we need to discus how to bind the security policy to the config doc
... could use the feature element
... Could add a new permissions element to the access element
... and it could contain a string that defines a permission

MC: do you have an example of use case?

PB: from MIDP, can use an API to open any channel (e.g. BT, Socket, HTTP)
... If want generic APIs, need a way to grant permissions

MP: may need to have different policies for different APIs

[ Marcos enters an example into his ED draft ]

<marcos> Option 1: <feature uri="http://geoloc.com/a/b/c/d/" />

<marcos> Option 2.<feature uri="http://geoloc.com">

AB: we will add this topic to the agenda this afternoon or tomorrow

Prep for URI scheme meeting with the TAG

[ Marcos shows preview of the slides he will present to the TAG ]

<scribe> ACTION: Marcos send Widget URI scheme slides to one of {member,public}-webapps [recorded in http://www.w3.org/2008/10/20-wam-minutes.html#action05]

<trackbot> Created ACTION-265 - Send Widget URI scheme slides to one of {member,public}-webapps [on Marcos Caceres - due 2008-10-27].

<timeless> ScribeNick timeless

Joint meeting with TAG Members regarding Widget URI scheme

<timeless> ScribeNick: timeless

<ArtB> AB: I chair this WG

<ArtB> MC: I am the Editor of this spec

<ArtB> NM: member of TAG from IBM

<ArtB> NW: Norm Walsh TAG

MC: [ presents slideshow "Widget URI Scheme" ]

<ArtB> DC: W3C, member of TAG

MC: Widget is a client side application - that runs on your computer
... primarily it's a light application, written using web technologies
... . Use cases include possibly embedding a widget into a web page
... - similar to embedding a flash applet into a web page
... - we aren't talking about Google Gadgets or Microsoft Gadgets
... . Our applications are packaged, they come in a zip file,
... all resources come in the file.
... We've gone through a requirements gathering phaze for the past two years
... OMTP has been gathering requirements for over a year.
... We have a landscape document which is undergoing review.
... And I'm also working on a Thesis describing this.
... Inside zip there is a header that says that the data contained in this file entry relates to this data.
... When you instantiate a widget, you need a way to tell the widget user agent that this widget
... resource lives within the zip file.
... The hierarchy refers to elements with-in the zip file.
... The reference exists within the DOM.
... We don't want the URI scheme to have the ability to reference things outside the resource.
... As we want to be able to embed widgets into web pages,
... we don't want them to conflict with browser handling.

<noah> Stefano Crosta.

AB: We have a slide for each of the candidates

MC: file:...
... with dashboard widgets, if you query the dom node for an image, it will expose the full path to the image
... including the username.
... The current specification for file is obsolete.
... There is a new document which doesn't specify, but merely indicates errors in the handling.

ABe: Using the file uri scheme is not an option for Opera
... as you can't reference a file: resource from another protocol.
... This reduces the number of possible exploits.

MC: Mike does HTML5 specify the security boundary for http<=>file?

MS: I don't believe it's that specific.

MC: cid:...
... my personal opinion is that it's underspecified, especially involving encoding.
... although it would be possible for widgets to specify this.

<DanC_lap> (cid: clearly doesn't meet the hierarchical requirement. the other arguments are much less strong)

<DanC_lap> Norm Walsh, aka NDW

NDW: If the packaging format was still open, then i think it could be considered

<DanC_lap> "obscure" applies to widget: too. (as does "no standard" from the file: slide)

NDW: but if you've already accepted Zip, then I understand that it doesn't fit.

MC: http:...
... TimBL proposed it.

<DanC_lap> (I wondered earlier if http://engine/widget/path was analagous to http://example.com/widgets/2007/blink-01.zip/contents/chrome/js/blink.js . indeed.)

Noah: do you have update scenairos.
... if so, then I think you need to posit update scenarios

<noah> If you have update scenarios, then you need to compare how the various schemes compare in supporting them.

<noah> If you don't need update, then I would say that the incremental cost of declining POST/PUT/DELETE in HTTP is very low.

MC: Suppose we do offer HTTP, then someone might choose to implement a server which did support POST

Noah: Don't compare widget: to http: based on the different baselines.
... only compare them against the same baseline.

ABe: in practice that would lead to user agents having two implementations of http.

<DanC_lap> DanC

DanC: yes

<noah> User agent or server? Seems to me it's the server that declines POST/PUT/DELETE

<DanC_lap> (two implementations of http: in browsers is cheaper to the rest of the community than two uri schemes)

NDW: I assume these names are just names and that they aren't bound to other things.

<noah> The user agent needs to respond properly to that status code. Existing user agents will do that, one would assume.

<DanC_lap> (we somehow switched from evaluating proposal against requirements to pros/cons. I'll hang on to see if we get back, I guess)

MC: We've got no notion of origin in our widgets.
... There's no notion of authority.
... if we're tweaking http too much, at what point is it no longer http?

DanC: tim's proposal is that the thing is on a web server.

Noah: there are two ways to model this
... in one model there's a web server in the form of a proxy.
... as long as there's some way to assign a uri to it.

MC: you're talking about identity.

JS: what happens when you die>

noah: that sucks< you can put that into the Cons list

<DanC_lap> (I gather widget: uses guids. you can stick guids in domain names, eg. 123412lkj132.noah-medelsohn.com )

noah: but what happens if someone goes to IANA and steals the widget protocol?

MC: the real use case for this is resolving the dom nodes.
... images, iframes, they all need to resolve to something.

<Norm> So, is it the case that you require the ordinary, web agent built-in URI resolution system to resolve the URI. That is, if it's http://example.org/... the web browser is going to do the natural thing

JS: then you have the security problems evidenced by MHTML, CHM and a couple of other packages with shadowing.

<Norm> ...which is to connect to that site.

<DanC_lap> (I heard him say they identify widgets with unrestricted URIs)

Noah: is it a potential pro that there's transparency so that the same widget could be deployed on the real web?

<Norm> I believe there's a distinction between identifying the widgets themselves, and the *resources inside the widgets*

Noah: granted that the caching is a complexity.

JS: widget model has atomicity
... and there's already an update spec which handles updates

AM: so you're describing something which is very specific to this case?
... it's just used for resolving names.

ABe: it's only a convenience for resolving resources

NDW: do you have a slide describing sample widget: uris?

MC: no (not a slide)

NDW: anything would be ok

<DanC_lap> (hmm... where did I see widget: with a guiid)

MC: we do have examples.

JS: DanC: one of the potential candidates...

MC: I'm just showing a few options

widget: //widgetEngine/pack.wgt/some/path
... //widgetEngine/pack.wgt/some/path/to/file
... //pack.wgt/some/path/to/file.png

NDW: so Noah and I have both made the world's greatest clock app?

widget: //{uuid}/path/to/file.png

<DanC_lap> (where do widget: uris occur? I gather only paths occur in href/src attributes)

BS: In terms of ...

Noah: traditionally when you have those things happening
... one is that you have something obscure (like a uuid)

<DanC_lap> (also, the "what happens when you die and somebody takes over your domain?" concern applies to /someEngine/ too, yes?)

Noah: are these things used to name the product?
... or are they something transient?
... If you're doing product naming then you have to run a registry.

MC: digital signature document covers some of this.

<Norm> scribenick: norm

<timeless> JS: Suppose that instead of dealing with two different people...

timeless: Suppose that instead of two people, you deal with one vendor and two installed instances of the same vendor.
... So you made the world's greatest clock, but I want to run it twice.
... This has to be allowed, some widget engine might not allow it, but we expect in the general case that it will be possible.
... For these things, the general expectation is that the names are local. They're just so that the widget can introspect itself.

<marcos> widget://widgetEngine/pack.wgt/some/path/to/file

<marcos> widget://pack.wgt/some/path/to/file.png

<marcos> widget://{uuid}/path/to/file.png

<marcos> widget://path/to/file

timeless: It shouldn't be able to be remotely readable. It's a privacy violation if you can see what else is running.

NM: You could just name them 1, 2, 3, 4,...

timeless: Without using those particular numbers.

DanC: Where do widget: get resolved?

timeless: In the DOM, where .source must be resolvable.
... For example, in img.src.

DanC: No one ever writes these things down?

timeless: You could, but it won't work.

NM: I wonder if the thing to choose would be a less-obvious, less intrusive name. If you said these things were for people to write down, then widget: is simple.
... But if you never expect them to be written down, you could pick a more obscure name.

???: These things might one day appear in other spaces.

<timeless> ABe: if MC would put dashboard back up

<scribe> scribenick: timeless

UNKNOWN_SPEAKER: the only potential i see for this to leak out

<MikeSmith> browser architecture in general also suggests that things leak out (e.g., from XUL into gecko core)

ABe: is a bizarre use case
... as you can see he has two clock instances

<Zakim> DanC_lap, you wanted to ask where widget: URIs typically occur

ABe: The possibility would be if you could package a skin for widgets

<Zakim> DanC_lap, you wanted to ask about js a la: if img.src = "widget://..."

MC: as you can see this leaks the full path
... the security model of these applications is not equivalent to file:
... per the package resource you must specify which privileges you need.
... e.g. network=true|false
... plugins=true|false
... and additional features
... and we have a seperate policy language to control what is actually allowed

DanC: so you guys are attacking the software installation problem

MC: yes

DanC: the slide layout changed for http

MC: no, i wasn't comparing the protocols against them
... I was hoping through the magic of transitions, you'd be convinced
... At this point we're open to anything
... But we see a lot of problems with http

DanC: you're certainly changing the software implementation of http

MC: there are going to be hundreds of things we'd have to say you can't do

with http

scribe: in terms of defining response codes.

Noah: to me what's going to be harder
... the problem might be that when you do an http request
... for some cases you're going to want to do a real http request
... and some cases you won't.

<DanC_lap> (I would use "subtle" where he used complex on the slide, but the point is pretty much the same)

MC: even the overhead of adding the overhead of http is code+weight

Noah: it's still very light as protocols.

DanC: did the requirements list the security policy, e.g. same origin, details?

<Norm> scribenick: Norm

timeless: So, one of the things that widgets will do is ask for access to HTTP
... So they might call home and do work with their well known server, and probably only that server
... There's a bugzilla appilication that does caching and it would be nice if I could use it for any bugzilla.
... It's just a widget I've installed (purchased actually, there's a real vendor for this).
... It's a bugzilla UI, but it has no relation to the code for the standard bugzilla UI
... One of the things we've prioritized is "Networked: true or false?"
... So it's going to access HTTP, it's going to want to phone home or talk to other servers, it's a purchased app that doesn't want to be shared

<MikeSmith> ArtB: ↑

ABe: Reusing http: introduces ambiguity, is http://widget.com/ a pointer into the widget or a pointer to a resource on the "real" example.com
... This is especially the case now that TLD has gone away.

Noah: Is this really a collision? What two things have the same name accidentally.

DanC: It's not a collision, it's the same thing, one way is to get it from the remote server and the other way is to get it from the cache.

ABe: Then there's the problem of the signed package.

<scribe> scribenick: timeless

Noah: usually a signature is an invariant

MC: when a signature changes, what do you do then?

AB: time check

MC: implementation detail...
... (Slide)
... hopefully i've proven to you that apple's solution of using file is a privacy issue and security risk

<DanC_lap> (ah... so "implementation detail" doesn't prohibit file:)

MC: I don't see leaving it as an implentation detail is an actual option

<Zakim> DanC_lap, you wanted to ask about the state of deployment and to explore the "implementation defined" proposal (e.g. run-time generated nonce scheme name)

<Norm> DanC: Why not just make up the scheme names on the fly?

<Norm> timeless: Scheme names can be added on the fly, after the application starts to run, so there would be the possibility of collision.

JS: ok

MC: we need to consider extensibility of the uri scheme

Noah: the design considerations are going to be very different in two instances

<DanC_lap> DanC: I'd sure like to hear a consistent answer about whether these are internal-only names or not.

Noah: make a decision about if it leaks out
... it feels wrong to design something hoping it doesn't leak out.

<Norm> JS: One possibility, though not likely, imagine that I make a game where you click on the right or the left image.

<Norm> ...If I store that in a preference (or maybe it's the base path of a theme)

<Norm> ...I strip off just the picture name and I have the name for the theme.

<Norm> ..The working assumption I have is that we could/would allow when you install an *instance* of a widget, the scheme could be frozen at that point.

<DanC_lap> "In addition, a conforming specification MUST recommend that a widget user agent implement a means to persistently store user preferences for each widget instance. " -- http://dev.w3.org/2006/waf/widgets-reqs/

<Norm> ...That means I persist the theme base up to the image point. I don't ever show it to the user, but I do use it and I do show it to the widget engine.

<Norm> DanC: So that's a pretty clear answer: these aren't just for a single, running instance

<Norm> JS: It's not usefully leaked out to a web server, but it's lifetime might be as long as that instance is installed.

Noah: it seems like you are exposing two things
... it seems like you're offering to have a management policy which shows groups of related instances

<Norm> JS: I think personally, the HTML5 has this persistence stuff which is new, I don't know what sort of user interface it has.

<Norm> ...Suppose it's like cookies, users can see related cookies. In today's scheme, the logical thing is the domain.

<Norm> ...As long as the widget user agent stores which widget got which random ID, it would be ok.

<Norm> ...Though it might be easier from an implementation perspective to split on the name instead of hashing it.

<Zakim> DanC_lap, you wanted to ask about guuids in widget: uris

Danc: is widget:uuid in your current draft

MC: it was in a draft, it is no longer

DanC: have you decided in favor/against?

MC: it's an open issue

DanC: what's state of the art?

ABe: Opera 9.6 on desktop and probably base for windows mobile and sybmian
... probably uses widget and some widgetuseragent generated bit
... it's only meaningful for the device
... it also establishes a security model for accessing things
... as the browser can reuse the cross domain security module
... we're using an identifier because it's an incredibly convinently way to establish a same origin policy

DanC: and the fact that it's not easily guessable
... if that it's not easily guessable is a requirement
... then that rules out domain names.

ABe: this is based on Opera's internal choices which predate the consensus (not yet established)
... of the working group

PB: Even if the unique identifier were guessed, knowing that, no widget would have any greater rights
... the hard to guess requirement comes from privacy,
... number of installed entities.

<DanC_lap> (I need to remember this bit about security constraints that suggest install-time names and talk with timbl about it. my brain is not a reliable storage medium now. I wonder if I should make a TAG tracker action.)

MC: the runtime will still block widget accessing other widgets because of identifier/origin crossing

JS: MC "instantiated a new instance of the clock widget"

ABe: currently that on Opera desktop involves downloading another instance

MC: I believe Apple downloads it again

BS: For windows, there's one on disk image and two memory instances.

ABe: whether instantiation involves by copying on disk or not is an implementation detail
... which doesn't affect the discussion at any point.

MC: TAG: do you feel we have enough grounds for a new uri scheme?
... if not, what do we need to do?

DanC: you need to establish the right requirements

AB: I agree we need to flesh out the requirements
... I think they're in the points MC listed but not fleshed out

<DanC_lap> (ArtB, is that in the requirements document?)

Noah: I think you need to establish for all time whether things leak out

JS: requirements doc is http://dev.w3.org/2006/waf/widgets-reqs/

http://dev.w3.org/2006/waf/widgets-reqs/#r36.-

Noah: if you think they're going to leak out....
... I would really look at the registry issues.

<Norm> NW: My position is roughly in line with Noah's. If you're going to allow these things to leak out, or if it's going to be valuable to share them, then I think the logical thing to do would be to use http: URIs in that case.

<Norm> ...And if you do that, I'd be highly motivated to see if it's possible to use http: for all the names so that you don't need to names.

MC: is there a precedent for a readonly server

DanC: i think debian package names

<DanC_lap> (debian package names are, in a way, grounded in http names)

MC: has someone written a spec which defined using readonly

DanC: TimBL asked the python people to make python package names into http uris

Noah: has anyone gone to the browser people
... to make a complicated proxy hack for http

MC: hsivonen of mozilla explained that it would be hard and cause conflicts.

AB: where do we do follow up? www-tag?

DanC: yes
... what's the time scale?

MC: we want to finish this within 3 months.

DanC: are there any test cases for this?

MC: no
... we're starting an implementation now

AB: coffee break

<DanC_lap> (I might have some more precedent bookmarked under "software installation" on delicious; network isn't happy. :-/)

<hlee7> hello

<ArtB> Chair: ArtB

<marcos> chairnick: Artb

<marcos> chair: Artb

Section 8.2, Step #11 - Need to describe what happens if the widget already exists

<ArtB> AB: http://dev.w3.org/2006/waf/widgets/#step-11

<ArtB> AB: if widget already exists, what do we do?

<ArtB> ABe: what do other impls do?

<ArtB> MC: Dashboard says "widget exists, do you want to override it?"

<ArtB> JS: not sure I understand why this is in Step 11

<ArtB> MC: agree, it's not really related to Step 11

<ArtB> ... but the issue needs to be addressed

<ArtB> JS: so the same widget cannot be installed more than once?

<ArtB> MC: that's correct

<ArtB> BS: is this based on file name?

<ArtB> MC: no it isn't

<ArtB> ... it is based on something internal

<ArtB> ABe: probably some id

<ArtB> ABe: this should probably be an impl detail

<ArtB> BS: not sure I agree

<ArtB> ... for Vista, it's based on file name

<ArtB> MC: On Dashboard, uses identifier in the plist file

<ArtB> AB: I tend to agree this should be an implementation detail

<ArtB> ... Let the UA decide what to do

<ArtB> ... Could also reflect a user preference

<ArtB> [ Marcos does some experimenting with Dashboard ... ]

<hendry> Opera 9.6 allows the same widget to be installed multiple times

<ArtB> MC: either it is an impl detail or we specify it :-)

<ArtB> MC: we need to specify something regarding update

<ArtB> ... versus installing a second widget with the same name/id as a previously installed widget

<ArtB> MC: part of the problem is that the config file is optional

<ArtB> PB: such a widget can never be considered identical to another widget

<ArtB> [ Marcos enumerates the various scenarios ]

<ArtB> ... 1. If no config file, they are treated as unique

<ArtB> ... 2. If config file, but no id attr, then they are treated as unique

<ArtB> ... 3. If config has an id attr, and id is the same on both, they are the same widget

<ArtB> see update spec)

<ArtB> ... 4. If config has an id attr and a version attr that is diff from the current installed version, then it is an update

<ArtB> ... per the Updates spec

<paddy> MIDP spec relating to ugrade procedure: http://jcp.org/en/jsr/detail?id=118

<hendry> apt-get remove --purge package && apt-get install package

<hendry> (how Debian works)

<ArtB> JS: users don't want to have any of their data removed during update

<ArtB> ... can always do some data pruning after the update is running

<ArtB> PB: Java have some conventions we can consider

<ArtB> MC: we've discussed comparing versions before

<ArtB> JS: can also take a look at what Mozilla has done

<ArtB> ... the application decides what to do

<hendry> debian version ref: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

<ArtB> MC: I've already looked at some various practices

<ArtB> ... We could recommend a rollback mechanism

<ArtB> [ Marcos displays MIDP 2.0's versioning mechanism ... ]

<ArtB> MC: is 1.02 < or > than 1.002?

<ArtB> PB: can't do 1.002

<hendry> http://lists.w3.org/Archives/Public/public-appformats/2007Sep/0006.html old version string discussion

<ArtB> ... limited to two decimals per number

<ArtB> ABe: what about one widget with more than one branding?

<ArtB> AB: I don't think we are getting consensus on this issue

<ArtB> MC: propose we leave the current model but recommend using MIDP model

<ArtB> PB: besides version number, we still have the original issue

<ArtB> MC: propose we recommend authors use MIDP model for versioning

for the record, http://archive.ubuntu.com/ubuntu/pool/multiverse/f/flashplugin-nonfree/flashplugin-nonfree_10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2.dsc

<ArtB> ACTION: Marcos will create the text and processing model to codify the four conditions enumerated above [recorded in http://www.w3.org/2008/10/20-wam-minutes.html#action06]

<trackbot> Created ACTION-271 - Will create the text and processing model to codify the four conditions enumerated above [on Marcos Caceres - due 2008-10-27].

<ArtB> ACTION: Marcos will create text to address the version string issue by recommending MIDP 2.0 model [recorded in http://www.w3.org/2008/10/20-wam-minutes.html#action07]

<trackbot> Created ACTION-272 - Will create text to address the version string issue by recommending MIDP 2.0 model [on Marcos Caceres - due 2008-10-27].

<ArtB> AB: We do need to careful about copyright issues

<ArtB> MC: I will create text that is "inspired by" the Java doc but will not copy it

Section 9.1 locating thumbnails

<ArtB> MC: it is a duplicate of the finding the icons issue

<ArtB> ... We don't need to discuss it

<ArtB> AB: Meeting Adjourned for today

- DRAFT -

Widgets f2f Meeting

20 Oct 2008

Attendees

Contents

Introductions

Agenda review and tweaking

Issue #46 - I18N

Section 5.4 Need validator's point of view

Section 5.5 Need for a MIME type

Version String in Section 6.14

Section 7 Need to add cp437 text

Section 8.2 - What do we do if run out of space?

Section 8.2, Step #10 - How to handle SVG Icon Formats

Section 8.2, Step #11 - Is additional security model needed here?

Prep for URI scheme meeting with the TAG

Joint meeting with TAG Members regarding Widget URI scheme

Section 8.2, Step #11 - Need to describe what happens if the widget already exists

Section 9.1 locating thumbnails

Summary of Action Items

Scribe.perl diagnostic output