The minutes from the October 20 Widgets f2f meeting are available at
the following and copied below:
<http://www.w3.org/2008/10/20-wam-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before October 23 (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
20 Oct 2008
[2]Agenda
[2] http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda
See also: [3]IRC log
[3] http://www.w3.org/2008/10/20-wam-irc
Attendees
Present
Mark, David, Claudio, Benoit, Marcos, Art, Arve, Mike,
Fabrice_Desre, Paddy, Josh, Sophie_Aveline, Hyunjeong_Lee,
Nick, Larry_Masinter, Dan_Connolly, Noah_M, Norm_Walsh,
Ashok_Malhotra, Oracle, TAG, Stefano_Crosta, Henri, Hixie,
Kai_Hendry
Regrets
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Introductions
2. [6]Agenda review and tweaking
3. [7]Issue #46 - I18N
4. [8]Section 5.4 Need validator's point of view
5. [9]Section 5.5 Need for a MIME type
6. [10]Version String in Section 6.14
7. [11]Section 7 Need to add cp437 text
8. [12]Section 8.2 - What do we do if run out of space?
9. [13]Section 8.2, Step #10 - How to handle SVG Icon Formats
10. [14]Section 8.2, Step #11 - Is additional security model
needed here?
11. [15]Prep for URI scheme meeting with the TAG
12. [16]Joint meeting with TAG Members regarding Widget URI
scheme
13. [17]Section 8.2, Step #11 - Need to describe what happens
if the widget already exists
14. [18]Section 9.1 locating thumbnails
* [19]Summary of Action Items
_________________________________________________________
<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:
[20]http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda
[20] 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
[21]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: [22]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
[22] http://dev.w3.org/2006/waf/widgets/#mime-type
[ 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: [23]http://dev.w3.org/2006/waf/widgets/#the-version (now in
section 6.15)
... what are you looking for?
[23] http://dev.w3.org/2006/waf/widgets/#the-version
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
[24]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
[25]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
[26]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
[27]http://dev.w3.org/2006/waf/widgets/#extracting
[27] 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 [28]http://dev.w3.org/2006/waf/widgets/#step-10
... what can we expect to do with this issue?
[28] http://dev.w3.org/2006/waf/widgets/#step-10
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: [29]http://dev.w3.org/2006/waf/widgets/#step-11
... what
... is the issue?
[29] http://dev.w3.org/2006/waf/widgets/#step-11
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="[30]http://geoloc.com/a/b/c/d/"; />
[30] http://geoloc.com/a/b/c/d/
<marcos> Option 2.<feature uri="[31]http://geoloc.com";>
[31] http://geoloc.com/
<marcos> <param name="celltowers" value="true"/>
<marcos> </feature>
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
[32]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 [33]http://engine/widget/path was
analagous to
[34]http://example.com/widgets/2007/blink-01.zip/contents/chrome/js/
blink.js . indeed.)
[33] http://engine/widget/path
[34] http://example.com/widgets/2007/blink-01.zip/contents/
chrome/js/blink.js
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
[35]http://example.org/... the web browser is going to do the
natural thing
[35] http://example.org/...
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 [36]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.
[36] http://widget.com/
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. " --
[37]http://dev.w3.org/2006/waf/widgets-reqs/
[37] 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 [38]http://dev.w3.org/2006/waf/widgets-reqs/
[38] http://dev.w3.org/2006/waf/widgets-reqs/
[39]http://dev.w3.org/2006/waf/widgets-reqs/#r36.-
[39] 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: [40]http://dev.w3.org/2006/waf/widgets/#step-11
[40] 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:
[41]http://jcp.org/en/jsr/detail?id=118
[41] 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:
[42]http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-
f-Version
[42] 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>
[43]http://lists.w3.org/Archives/Public/public-appformats/2007Sep/00
06.html old version string discussion
[43] http://lists.w3.org/Archives/Public/public-appformats/
2007Sep/0006.html
<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,
[44]http://archive.ubuntu.com/ubuntu/pool/multiverse/f/flashplugin-n
onfree/flashplugin-nonfree_10.0.1.218+10.0.0.525ubuntu1~hardy1+reall
y9.0.124.0ubuntu2.dsc
[44] 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
[45]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
[46]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
Summary of Action Items
[NEW] ACTION: Barstow determine the status of URI Template RFC and
report back to WG [recorded in
[47]http://www.w3.org/2008/10/20-wam-minutes.html#action04]
[NEW] ACTION: Barstow see if the W3C systeam/webreq can help with a
conformance checker [recorded in
[48]http://www.w3.org/2008/10/20-wam-minutes.html#action01]
[NEW] ACTION: Macros move the version string section from P&C spec
to the Updates spec [recorded in
[49]http://www.w3.org/2008/10/20-wam-minutes.html#action02]
[NEW] ACTION: Marcos move the version string section from P&C spec
to the Updates spec [recorded in
[50]http://www.w3.org/2008/10/20-wam-minutes.html#action03]
[NEW] ACTION: Marcos send Widget URI scheme slides to one of
{member,public}-webapps [recorded in
[51]http://www.w3.org/2008/10/20-wam-minutes.html#action05]
[NEW] ACTION: Marcos will create text to address the version string
issue by recommending MIDP 2.0 model [recorded in
[52]http://www.w3.org/2008/10/20-wam-minutes.html#action07]
[NEW] ACTION: Marcos will create the text and processing model to
codify the four conditions enumerated above [recorded in
[53]http://www.w3.org/2008/10/20-wam-minutes.html#action06]
[End of minutes]
[59] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
