IRC log of wam on 2008-10-20

Timestamps are in UTC.

07:17:18 [RRSAgent]
RRSAgent has joined #wam
07:17:18 [RRSAgent]
logging to
07:17:24 [timeless]
that reminds me, i should d/l the maps + favorite the addresses
07:17:43 [abarsto]
Meeting: Widgets f2f Meeting
07:17:48 [abarsto]
Date: 20 October 2008
07:18:04 [abarsto]
07:18:14 [abarsto]
Chair: Art
07:18:17 [abarsto]
Scribe: Art
07:18:22 [abarsto]
ScribeNick: ArtB
07:19:11 [abarsto]
Present: Mark, David, Claudio, Benoit, Marcos, Art, Arve, Mike, Fabrice_Desre
07:20:19 [timeless]
10a. Can you invite zakim?
07:20:28 [Zakim]
Zakim has joined #wam
07:20:44 [abarsto]
zakim, this is Widgets
07:20:44 [Zakim]
ok, abarsto; that matches IA_WebApps(Widgets)3:00AM
07:20:45 [marcos]
marcos has joined #wam
07:26:54 [abarsto]
Topic: Introductions
07:28:15 [abarsto]
[ round robin of Widgets people mostly ]
07:28:25 [abarsto]
Fabrice: Orange/FT AC rep
07:28:40 [abarsto]
Topic: Agenda review and tweaking
07:28:53 [abarsto]
AB: agenda:
07:32:40 [abarsto]
AB: any changes or additions?
07:32:56 [abarsto]
MP: what about OpenAjax's API style guide?
07:33:36 [abarsto]
AB: how about I add it to AOB?
07:33:39 [abarsto]
07:33:54 [abarsto]
AB: I can also ask Chaals to let us know if/when he discusses it
07:35:21 [abarsto]
Topic: Issue #46 - I18N
07:35:42 [abarsto]
AB: what remains to be done with this issue?
07:36:05 [abarsto]
MC: I have addressed this issue in the spec
07:36:27 [abarsto]
... The main issue is how to address LtoR and RtoL in the same piece of text
07:36:41 [abarsto]
... I added OPTIONAL support for the ITS' span element
07:37:40 [abarsto]
... If supported must support its:dir atrribute too
07:38:09 [abarsto]
... Not clear if we need to bind its:dir to widgets description or name element.
07:38:20 [abarsto]
... Thus I need to clarify with the I18N WG
07:38:35 [abarsto]
... This also means I needed to change our RELAXNG schema
07:39:45 [abarsto]
AB: any recommendations on the its:dir binding issue?
07:40:07 [abarsto]
... It would be optional, right?
07:40:13 [abarsto]
MC: yes, it would be optional
07:40:25 [abarsto]
AB: OK, so we leave this open for now
07:40:46 [abarsto]
... and try to close it by the end of this meeting.
07:41:00 [abarsto]
MC: If I can meet with Felix we can close this today
07:41:07 [abarsto]
MS: yes, I can make that intro.
07:53:21 [Zakim]
07:53:23 [Zakim]
IA_WebApps(Widgets)3:00AM has ended
07:53:23 [Zakim]
Attendees were Josh_Soref
07:56:17 [tlr]
tlr has joined #wam
07:56:21 [drogersuk]
drogersuk has joined #wam
07:58:20 [arve]
arve has joined #wam
07:58:47 [ArtB]
ArtB has joined #wam
07:59:01 [ArtB]
RRSAgent, make minutes
07:59:01 [RRSAgent]
I have made the request to generate ArtB
07:59:55 [cla]
cla has joined #wam
08:00:12 [ArtB]
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?
08:00:43 [ArtB]
RRSAgent, make log public
08:00:48 [ArtB]
RRSAgent, make minutes
08:00:48 [RRSAgent]
I have made the request to generate ArtB
08:01:17 [ArtB]
[ MC demonstrates some of the interop issues ... ]
08:01:37 [ArtB]
AB: what's the action plan?
08:01:45 [ArtB]
MC: I need to implement what's spec'ed
08:02:11 [ArtB]
AB: does this need to be done before LC?
08:02:18 [ArtB]
MC: yes
08:02:20 [MikeSmith]
MikeSmith has joined #wam
08:02:27 [ArtB]
AB: can anyone help Marcos?
08:02:45 [ArtB]
[ No voluneeters :-( ]
08:03:23 [ArtB]
BS: can someone here at the TPAC help?
08:03:49 [ArtB]
MC: it's a bit ugly and nitty-gritty
08:03:53 [ArtB]
... but I can do it
08:04:05 [ArtB]
... Need to actually look at the ZIP files in hex
08:04:31 [ArtB]
[ MC shows HexEdit example of a .zip file ]
08:05:17 [Zakim]
IA_WebApps(Widgets)3:00AM has now started
08:05:25 [Zakim]
08:05:53 [ArtB]
ScribeNick: ArtB
08:06:18 [ArtB]
Present+ Paddy
08:07:18 [shepazu]
shepazu has joined #wam
08:08:05 [ArtB]
MC: if not utf8, use cp437
08:08:12 [MikeSmith]
Zakim, call Mike
08:08:13 [Zakim]
ok, MikeSmith; the call is being made
08:08:14 [Zakim]
08:08:57 [MikeSmith]
Zakim, call Iles_A
08:08:57 [Zakim]
ok, MikeSmith; the call is being made
08:08:58 [Zakim]
08:10:02 [ArtB]
MC: I think Josh can help me
08:10:06 [ArtB]
Present+ Josh
08:10:10 [MikeSmith]
Zakim, drop Mike
08:10:10 [Zakim]
Mike is being disconnected
08:10:10 [Zakim]
08:10:52 [ArtB]
RRSAgent, make minutes
08:10:52 [RRSAgent]
I have made the request to generate ArtB
08:12:59 [ArtB]
Topic: Section 5.4 Need validator's point of view
08:13:05 [ArtB]
MC: this was raised by Dom
08:13:41 [ArtB]
... I added some related text to the definitions
08:14:09 [ArtB]
... Also need to reflect the view of a validator
08:14:26 [ArtB]
... I don't think this is a high priority
08:14:37 [ArtB]
... If someone wants to contribute, that would be good
08:14:55 [ArtB]
AB: any volunteers for a conformance checker?
08:15:19 [ArtB]
... perhaps we can some W3C staff/webreq help
08:15:24 [ArtB]
... I'll check with Mike
08:15:44 [ArtB]
ACTION: Barstow see if the W3C systeam/webreq can help with a conformance checker
08:15:44 [trackbot]
Created ACTION-257 - See if the W3C systeam/webreq can help with a conformance checker [on Arthur Barstow - due 2008-10-27].
08:15:47 [marcos]
marcos has joined #wam
08:16:17 [mpriestl]
mpriestl has joined #wam
08:17:08 [ArtB]
AB: I would imagine that type of service could be included in a Widget repository service
08:17:41 [ArtB]
MC: something like this could be added to
08:17:49 [ArtB]
AB: this is Henri's service?
08:18:19 [ArtB]
MC: yes, but just giving a schema isn't that helpful
08:18:32 [ArtB]
.. need to provide "hints" too
08:19:08 [ArtB]
... I believe is Open Source so we could roll our own service
08:20:10 [ArtB]
MC: the note in Section 5.4 has been removed since I think its priority is too low
08:20:35 [ArtB]
Topic: Section 5.5 Need for a MIME type
08:20:52 [ArtB]
08:21:59 [ArtB]
AB: a potential sub-issue here is Security Concerns
08:22:40 [ArtB]
AB: I would expect IANA to have a template for what's required
08:23:31 [ArtB]
... RFC 4289 defines the process
08:28:03 [Zakim]
08:29:29 [ArtB]
[ We spend some type looking at the W3C/IANA MIME registration procedures ]
08:29:40 [ArtB]
AB: do we need to complete the template?
08:29:51 [ArtB]
... We can check the precedence
08:30:17 [ArtB]
AB: a question I have is if we need to complete the template before we publish a LC doc
08:31:49 [ArtB]
Topic: Version String in Section 6.14
08:32:11 [ArtB]
AB: (now in section 6.15)
08:32:18 [ArtB]
AB: what are you looking for?
08:32:23 [ArtB]
MC: that should be there
08:32:41 [ArtB]
s/should be there/should not be there/
08:32:58 [ArtB]
MC: this should be in the update spec, not P&C
08:33:25 [ArtB]
MP: if it is in the Update spec then where?
08:33:32 [ArtB]
MC: in the update element
08:34:09 [ArtB]
MP: if you want version info in the widget but won't have an update, what do you do?
08:35:27 [ArtB]
PB: so version attribute on widget element remains?
08:35:30 [ArtB]
MC: yes
08:36:03 [ArtB]
AB: so the update element will have a verison attribute too?
08:36:05 [ArtB]
MC: yes
08:37:28 [arve]
arve has joined #wam
08:38:11 [ArtB]
ACTION: Macros move the version string section from P&C spec to the Updates spec
08:38:11 [trackbot]
Sorry, couldn't find user - Macros
08:38:53 [ArtB]
ACTION: Marcos move the version string section from P&C spec to the Updates spec
08:38:53 [trackbot]
Created ACTION-260 - Move the version string section from P&C spec to the Updates spec [on Marcos Caceres - due 2008-10-27].
08:41:09 [ArtB]
MC: there is another spec being written by David Orchard re template for attributes
08:41:39 [ArtB]
... I have used text from URI Template (RFC working draft)
08:41:52 [timeless]
timeless has joined #wam
08:42:21 [ArtB]
ACTION: Barstow determine the status of URI Template RFC and report back to WG
08:42:21 [trackbot]
Created ACTION-261 - Determine the status of URI Template RFC and report back to WG [on Arthur Barstow - due 2008-10-27].
08:43:29 [ArtB]
MC: another discussion we can have is the use of this template mechanism for other elements in the Updates spec
08:44:02 [ArtB]
AB: do we need to consider its usage in the P&C spec?
08:44:03 [ArtB]
MC: no
08:48:35 [ArtB]
MC: we can use OMA's DL spec e.g. for status codes
08:48:44 [ArtB]
... regarding the Update spec.
08:50:37 [ArtB]
Topic: Section 7 Need to add cp437 text
08:50:55 [ArtB]
AB: the agenda mentions this issue but I think it has now been addressed
08:51:00 [ArtB]
... Is that right, Marcos?
08:51:33 [ArtB]
MC: yes, consider this part of the URI/IRI proc model discussion we had earlier.
08:51:42 [ArtB]
[ Take a Coffee Break ]
08:51:50 [ArtB]
RRSAgent, make minutes
08:51:50 [RRSAgent]
I have made the request to generate ArtB
09:05:55 [tlr]
tlr has joined #wam
09:23:48 [ArtB]
Present+ Sophie_Aveline
09:24:08 [drogersuk]
drogersuk has joined #wam
09:24:45 [ArtB]
Present+ Hyunjeong_Lee
09:25:04 [ArtB]
Present+ Nick
09:25:50 [ArtB]
Topic: Section 8.2 - What do we do if run out of space?
09:25:54 [ArtB]
AB: status Marcos?
09:26:08 [ArtB]
MC: I removed this because it is an implementation issue
09:26:21 [ArtB]
... Josh added this
09:26:37 [ArtB]
ABe: I agree it is an implementation detail for the P&C spec
09:26:56 [ArtB]
... also agree it is a real implemenation detail for an implemenation
09:27:39 [claudio]
claudio has joined #wam
09:28:22 [ArtB]
MC: I changed related text
09:30:06 [ArtB]
ABe: I think the new text is sufficient
09:30:18 [ArtB]
AB: Josh, what do you think (you raised this issue)?
09:31:42 [ArtB]
MC: I would expect an impl to use the ZIP header to determine the space needed and do the right thing
09:32:00 [ArtB]
JS: this is OK with me
09:32:32 [ArtB]
Topic: Section 8.2, Step #10 - How to handle SVG Icon Formats
09:32:54 [ArtB]
AB: see
09:34:07 [ArtB]
AB: what can we expect to do with this issue?
09:34:16 [ArtB]
MC: we need feedback from implementors
09:34:50 [ArtB]
... need to understand the interactivity e.g. if the SVG has some JavaScript
09:35:13 [paddy]
paddy has joined #wam
09:35:14 [ArtB]
ABe: the JS could run outside of the widget
09:35:30 [ArtB]
... We wouldn't be able to do anything about security in that case
09:35:52 [arve]
arve has joined #wam
09:36:13 [ArtB]
MC: my feeling is we should drop SVG for v1
09:36:20 [ArtB]
... and add it to v2
09:36:54 [ArtB]
ABe: the problem that will introduce is that most operators will require SVG for icon formats
09:37:02 [ArtB]
MP: yes, I believe that is true for us
09:37:35 [ArtB]
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
09:38:17 [ArtB]
CV: we need to support SVG Tiny
09:38:40 [ArtB]
... and 1.2 is preferred
09:38:54 [ArtB]
MC: we have an open issue regarding 1.1 vs 1.2
09:39:21 [ArtB]
MC: the issue is how to handle the events on the icon e.g. via XHR
09:39:54 [ArtB]
... the question is do we allow that
09:40:13 [ArtB]
... Will it introduce too much implementation burden
09:40:58 [ArtB]
BS: think the most important requirement is the image format
09:41:07 [ArtB]
.. and interactivity is secondary importance
09:41:18 [ArtB]
s/.. and/... and/
09:41:43 [ArtB]
... I think the most common usage is static icon images
09:42:40 [ArtB]
AB: any other comments?
09:42:54 [ArtB]
MC: I think we should leave this as an impl detail
09:43:22 [ArtB]
... it is optional to support SVG as an icon format
09:43:51 [ArtB]
AB: if we do that, what interop probs will there be?
09:45:07 [ArtB]
JS: could add a should for widget authors re SVG icon format
09:46:01 [ArtB]
ABe: not sure about use of should; could be too strong
09:46:17 [ArtB]
... perhaps should use MAY
09:46:42 [ArtB]
MC: I've stopped using normative text regarding authoring reqs
09:46:51 [ArtB]
JS: so it's more of a hint in this case?
09:46:53 [ArtB]
MC: yes
09:47:02 [ArtB]
ABe: we could remove the entire author req
09:47:12 [ArtB]
MC: no, I disagree; want to keep it
09:47:25 [ArtB]
MC: but those who want it will add; otherwise they won't
09:48:07 [ArtB]
AB: are these "Author Requirements" non-normative?
09:48:21 [ArtB]
MS: don't call them "Guidelines"
09:48:43 [ArtB]
... perhaps they should be in a sep doc
09:48:52 [ArtB]
JS: we could leave them in for now
09:49:03 [ArtB]
MC: yes, they could be in a separate doc
09:49:52 [ArtB]
AB: are these Autho Reqs normative or non-normative?
09:50:07 [ArtB]
MC: I think they should be Normative
09:51:12 [ArtB]
MS: If we are going to build a validator, they should be Normative
09:52:07 [ArtB]
MS: are there constraints that cannot be expressed in a schema?
09:52:15 [ArtB]
MC: yes, some of the ZIP constraints
09:52:40 [ArtB]
MS: if you want these reqs to be in the validator, they should be Normative
09:52:53 [ArtB]
MC: agree; DOM raised a similar issue
09:53:36 [ArtB]
Present+ Larry_Masinter
09:54:11 [ArtB]
MC: perhaps the Author reqs should be changed to "Conformance Checker"
09:54:39 [ArtB]
MS: that is what HTML5 does
09:54:54 [ArtB]
... with some text to qualify relationship to authoring
09:55:34 [ArtB]
MC: I can re-write all of the Author Reqs to Conformance Reqs and make them all Normative
09:56:04 [ArtB]
AB: any objections?
09:56:11 [ArtB]
[ None ]
09:56:24 [ArtB]
JS: should we check with Hixie re HTML5?
09:56:40 [ArtB]
MC: I talked to HTML5 this morning
09:56:59 [ArtB]
... he is considering a script to move authoring stuff into a sep doc
09:57:43 [ArtB]
JS: I'm OK with doing this way
09:57:55 [ArtB]
MC: there is another issue
09:58:16 [ArtB]
... this could be a problem if we add a new "Product"
09:58:33 [ArtB]
... We would now have a 4th product.
09:59:03 [ArtB]
... And the Conformance Checker can claim conformance to the spec
09:59:15 [ArtB]
AB: can you do that?
09:59:19 [ArtB]
MC: yes, I can do that
09:59:34 [ArtB]
... let someone else create the Conformance Checker.
09:59:40 [ArtB]
AB: any volunteers?
10:00:30 [arve]
arve has joined #wam
10:01:05 [ArtB]
RESOLUTION: all of the Author requirements will be changed to Conformance Checker requirements and all of these requirements will be Normative.
10:01:25 [ArtB]
LM: I don't recall seeing a good definition of Conformance Checker
10:01:32 [ArtB]
MC: I hope that isn't a rat hole
10:02:04 [ArtB]
MC: HTML5 attempts to make such a definition
10:02:17 [ArtB]
MS: we could look at what has been done in HTML5
10:03:47 [ArtB]
Topic: Section 8.2, Step #11 - Is additional security model needed here?
10:04:07 [ArtB]
10:04:44 [ArtB]
AB: what
10:04:50 [ArtB]
... is the issue?
10:05:08 [ArtB]
MC: this may be out of scope for this spec
10:05:53 [ArtB]
... Not sure we need to go beyond what is specified
10:06:27 [ArtB]
AB: what do people think?
10:07:07 [ArtB]
PB: not sure what the security issue is
10:07:34 [ArtB]
MC: need to spec how to put something on the screen and what we need to say about runtime requirements
10:07:59 [ArtB]
... eg. if the widget tries to do something that raises a security exception
10:08:52 [ArtB]
... What do we specify regarding instantiation e.g. security policies
10:09:17 [ArtB]
MC: does HTML5 deal with this?
10:09:35 [ArtB]
MS: the latest ED of HTMl5 doesn't say anything about rendering
10:09:51 [ArtB]
MC: I could talk to Hixie
10:10:03 [ArtB]
MS: we could ask for an Editor to draft some text
10:10:48 [ArtB]
PB: within BONDI, we are interesting in the security policy related to the instantiation
10:11:02 [ArtB]
s/are interesting/are interested/
10:11:39 [ArtB]
MC: we used to have a step #12 which tried to deal with this
10:11:53 [ArtB]
... but it was remove because this is out of scope
10:12:46 [ArtB]
AB: I'm OK with leaving step #11 as is
10:15:49 [ArtB]
AB: any objections to deleting the security model issue from Step #11?
10:15:55 [ArtB]
[ None ]
10:16:28 [ArtB]
RESOLUTION: Step #11 of the P&C will not address the security model
10:17:39 [ArtB]
ABe: I'm uncomfortable with separating the P&C spec from Security Model
10:17:57 [ArtB]
... e.g. it could create some new authoring issues
10:18:06 [ArtB]
MC: we do need to spec the security models
10:18:23 [ArtB]
... expect BONDI to do some relevant work here that we may be able to use
10:18:45 [ArtB]
... expect a separate policy doc from the config doc
10:19:07 [ArtB]
MP: agree, we envision the policy doc as a separate from the config doc
10:19:41 [ArtB]
MC: we could bind the config doc to the policy doc via the feature element
10:20:49 [ArtB]
MP: we need to discus how to bind the security policy to the config doc
10:20:54 [ArtB]
... could use the feature element
10:21:20 [ArtB]
... Could add a new permissions element to the access element
10:21:32 [ArtB]
... and it could contain a string that defines a permission
10:22:08 [ArtB]
MC: do you have an example of use case?
10:22:47 [ArtB]
PB: from MIDP, can use an API to open any channel (e.g. BT, Socket, HTTP)
10:23:30 [ArtB]
... If want generic APIs, need a way to grant permissions
10:24:43 [ArtB]
MP: may need to have different policies for different APIs
10:25:33 [ArtB]
[ Marcos enters an example into his ED draft ]
10:27:42 [marcos]
Option 1: <feature uri="" />
10:27:58 [marcos]
Option 2.<feature uri="">
10:27:58 [marcos]
<param name="celltowers" value="true"/>
10:27:58 [marcos]
10:28:49 [ArtB]
AB: we will add this topic to the agenda this afternoon or tomorrow
11:38:44 [ArtB]
ArtB has joined #wam
11:39:06 [ArtB]
RRSAgent, make minutes
11:39:06 [RRSAgent]
I have made the request to generate ArtB
11:39:56 [ArtB]
RRSAgent, make minutes
11:39:56 [RRSAgent]
I have made the request to generate ArtB
11:43:00 [paddy]
paddy has joined #wam
11:43:48 [drogersuk]
drogersuk has joined #wam
11:44:19 [claudio]
claudio has joined #wam
11:45:41 [ArtB]
Topic: Prep for URI scheme meeting with the TAG
11:48:33 [ArtB]
[ Marcos shows preview of the slides he will present to the TAG ]
11:54:57 [mpriestl]
mpriestl has joined #wam
11:55:05 [ArtB]
ACTION: Marcos send Widget URI scheme slides to one of {member,public}-webapps
11:55:05 [trackbot]
Created ACTION-265 - Send Widget URI scheme slides to one of {member,public}-webapps [on Marcos Caceres - due 2008-10-27].
11:58:27 [timeless]
ScribeNick timeless
11:58:38 [arve]
arve has joined #wam
11:58:56 [ArtB]
Topic: Joint meeting with TAG Members regarding Widget URI scheme
11:59:05 [ArtB]
Present+ Dan_Connolly
11:59:12 [ArtB]
Present+ Noah_M
11:59:22 [ArtB]
Present+ Norm_Walsh
11:59:44 [timeless]
ScribeNick: timeless
11:59:45 [Norm]
Norm has joined #wam
12:00:28 [marcos]
marcos has joined #wam
12:02:12 [ArtB]
AB: I chair this WG
12:02:21 [ArtB]
MC: I am the Editor of this spec
12:02:53 [noah]
noah has joined #wam
12:03:11 [ArtB]
NM: member of TAG from IBM
12:03:18 [ArtB]
NW: Norm Walsh TAG
12:03:43 [ArtB]
Present+ Ashok Oragle, TAG
12:04:53 [Norm]
s/Oragle/Malhotra, Oracle/
12:05:54 [timeless]
MC: [ presents slideshow "Widget URI Scheme" ]
12:05:57 [ArtB]
DC: W3CD, member of TAG
12:06:06 [ArtB]
12:06:28 [timeless]
MC: Widget is a client side application - that runs on your computer
12:06:54 [timeless]
... primarily it's a light application, written using web technologies
12:07:14 [timeless]
... . Use cases include possibly embedding a widget into a web page
12:07:32 [timeless]
... - similar to embedding a flash applet into a web page
12:07:47 [timeless]
... - we aren't talking about Google Gadgets or Microsoft Gadgets
12:08:04 [timeless]
... . Our applications are packaged, they come in a zip file,
12:08:18 [timeless]
... all resources come in the file.
12:08:40 [timeless]
... We've gone through a requirements gathering phaze for the past two years
12:08:52 [timeless]
... OMTP has been gathering requirements for over a year.
12:08:53 [kapyaho]
kapyaho has joined #wam
12:09:07 [timeless]
... We have a landscape document which is undergoing review.
12:09:22 [timeless]
... And I'm also working on a Thesis describing this.
12:09:54 [timeless]
... Inside zip there is a header that says that the data contained in this file entry relates to this data.
12:10:34 [timeless]
... When you instantiate a widget, you need a way to tell the widget user agent that this widget
12:10:45 [timeless]
... resource lives within the zip file.
12:11:01 [timeless]
... The hierarchy refers to elements with-in the zip file.
12:11:10 [timeless]
... The reference exists within the DOM.
12:11:45 [Norm]
Norm has joined #wam
12:11:50 [timeless]
... We don't want the URI scheme to have the ability to reference things outside the resource.
12:12:06 [timeless]
... As we want to be able to embed widgets into web pages,
12:12:52 [timeless]
... we don't want them to conflict with browser handling.
12:13:00 [noah]
Stefano Crosta.
12:13:01 [MikeSmith]
MikeSmith has joined #wam
12:13:11 [timeless]
Present+ Stefano_Crosta
12:13:46 [timeless]
AB: We have a slide for each of the candidates
12:13:54 [timeless]
MC: file:...
12:14:19 [timeless]
... with dashboard widgets, if you query the dom node for an image, it will expose the full path to the image
12:14:31 [timeless]
... including the username.
12:15:16 [timeless]
... The current specification for file is obsolete.
12:15:36 [timeless]
... There is a new document which doesn't specify, but merely indicates errors in the handling.
12:16:09 [timeless]
ABe: Using the file uri scheme is not an option for Opera
12:16:34 [timeless]
... as you can't reference a file: resource from another protocol.
12:17:06 [timeless]
... This reduces the number of possible exploits.
12:17:42 [timeless]
MC: Mike does HTML5 specify the security boundary for http<=>file?
12:17:52 [timeless]
MS: I don't believe it's that specific.
12:18:11 [DanC_lap]
DanC_lap has joined #wam
12:18:28 [timeless]
MC: cid:...
12:18:51 [ArtB]
ArtB has changed the topic to: WebApps WG's Widgets f2f meeting
12:19:35 [timeless]
... my personal opinion is that it's underspecified, especially involving encoding.
12:19:54 [timeless]
... although it would be possible for widgets to specify this.
12:20:07 [DanC_lap]
(cid: clearly doesn't meet the hierarchical requirement. the other arguments are much less strong)
12:20:17 [DanC_lap]
Norm Walsh, aka NDW
12:20:28 [Benoit]
Benoit has joined #wam
12:20:43 [timeless]
NDW: If the packaging format was still open, then i think it could be considered
12:20:52 [DanC_lap]
"obscure" applies to widget: too. (as does "no standard" from the file: slide)
12:21:00 [timeless]
... but if you've already accepted Zip, then I understand that it doesn't fit.
12:21:27 [timeless]
MC: http:...
12:21:45 [timeless]
... TimBL proposed it.
12:23:58 [hendry]
hendry has joined #wam
12:24:05 [DanC_lap]
(I wondered earlier if http://engine/widget/path was analagous to . indeed.)
12:24:18 [timeless]
Noah: do you have update scenairos.
12:24:37 [timeless]
... if so, then I think you need to posit update scenarios
12:24:58 [noah]
If you have update scenarios, then you need to compare how the various schemes compare in supporting them.
12:25:04 [arve]
arve has joined #wam
12:25:22 [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.
12:25:39 [Norm]
q+ to observe that names and interactions are separate concerns
12:25:41 [timeless]
MC: Suppose we do offer HTTP, then someone might choose to implement a server which did support POST
12:25:55 [stefanocrosta]
stefanocrosta has joined #wam
12:26:17 [timeless]
Noah: Don't compare widget: to http: based on the different baselines.
12:26:24 [timeless]
... only compare them against the same baseline.
12:26:26 [Norm]
12:26:48 [timeless]
ABe: in practice that would lead to user agents having two implementations of http.
12:26:57 [DanC_lap]
12:27:03 [timeless]
DanC: yes
12:27:27 [noah]
User agent or server? Seems to me it's the server that declines POST/PUT/DELETE
12:27:30 [DanC_lap]
(two implementations of http: in browsers is cheaper to the rest of the community than two uri schemes)
12:27:51 [timeless]
NDW: I assume these names are just names and that they aren't bound to other things.
12:27:57 [noah]
The user agent needs to respond properly to that status code. Existing user agents will do that, one would assume.
12:28:11 [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)
12:28:23 [timeless]
MC: We've got no notion of origin in our widgets.
12:28:31 [timeless]
MC: There's no notion of authority.
12:28:47 [timeless]
... if we're tweaking http too much, at what point is it no longer http?
12:29:05 [timeless]
Noah: tim's proposal is that the thing is on a web server.
12:30:54 [timeless]
Noah: there are two ways to model this
12:31:02 [timeless]
... in one model there's a web server in the form of a proxy.
12:31:25 [timeless]
... as long as there's some way to assign a uri to it.
12:31:57 [timeless]
MC: you're talking about identity.
12:32:36 [timeless]
JS: what happens when you die>
12:32:52 [timeless]
noah: that sucks< you can put that into the Cons list
12:32:55 [DanC_lap]
(I gather widget: uses guids. you can stick guids in domain names, eg. )
12:32:59 [ArtB]
Present+ Henri
12:33:05 [ArtB]
Present+ Hixie
12:33:10 [timeless]
noah: but what happens if someone goes to IANA and steals the widget protocol?
12:33:26 [timeless]
MC: the real use case for this is resolving the dom nodes.
12:33:42 [timeless]
... images, iframes, they all need to resolve to something.
12:34:16 [DanC_lap]
s/Noah: tim's proposal/DanC: tim's proposal/
12:35:15 [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 the web browser is going to do the natural thing
12:35:17 [timeless]
JS: then you have the security problems evidenced by MHTML, CHM and a couple of other packages with shadowing.
12:35:24 [Norm]
...which is to connect to that site.
12:35:40 [DanC_lap]
(I heard him say they identify widgets with unrestricted URIs)
12:36:03 [timeless]
Noah: is it a potential pro that there's transparency so that the same widget could be deployed on the real web?
12:36:07 [Norm]
I believe there's a distinction between identifying the widgets themselves, and the *resources inside the widgets*
12:36:17 [timeless]
... granted that the caching is a complexity.
12:37:31 [timeless]
JS: widget model has atomicity
12:37:55 [timeless]
... and there's already an update spec which handles updates
12:37:58 [tlr]
tlr has joined #wam
12:38:15 [timeless]
AM: so you're describing something which is very specific to this case
12:38:25 [timeless]
... it's just used for resolving names.
12:38:32 [DanC_lap]
s/this case/this case?/
12:38:37 [timeless]
Abe: it's only a convenience for resolving resources
12:38:43 [timeless]
12:38:49 [RRSAgent]
I have made the request to generate ArtB
12:39:25 [timeless]
NDW: do you have a slide describing sample widget: uris?
12:39:32 [timeless]
MC: no (not a slide)
12:39:39 [timeless]
NDW: anything would be ok
12:39:48 [DanC_lap]
(hmm... where did I see widget: with a guiid)
12:39:48 [timeless]
MC: we do have examples.
12:40:07 [timeless]
JS: DanC: one of the potential candidates...
12:40:35 [timeless]
MC: I'm just showing a few options
12:40:55 [timeless]
12:41:01 [timeless]
12:41:17 [timeless]
12:42:03 [timeless]
12:42:21 [DanC_lap]
(where do widget: uris occur? I gather only paths occur in href/src attributes)
12:42:28 [timeless]
BS: In terms of ...
12:42:41 [timeless]
Noah: traditionally when you have those things happening
12:42:57 [timeless]
... one is that you have something obscure (like a uuid)
12:43:05 [DanC_lap]
(also, the "what happens when you die and somebody takes over your domain?" concern applies to /someEngine/ too, yes?)
12:43:15 [timeless]
... are these things used to name the product?
12:43:30 [timeless]
... or are they something transient?
12:43:51 [timeless]
... If you're doing product naming then you have to run a registry.
12:44:27 [timeless]
MC: digital signature document covers some of this.
12:44:34 [DanC_lap]
q+ to ask where widget: URIs typically occur
12:44:37 [Norm]
scribenick: norm
12:44:50 [timeless]
JS: Suppose that instead of dealing with two different people...
12:45:03 [Norm]
timeless: Suppose that instead of two people, you deal with one vendor and two installed instances of the same vendor.
12:45:14 [Norm]
...So you made the world's greatest clock, but I want to run it twice.
12:45:34 [Norm]
...This has to be allowed, some widget engine might not allow it, but we expect in the general case that it will be possible.
12:45:55 [Norm]
...For these things, the general expectation is that the names are local. They're just so that the widget can introspect itself.
12:45:56 [marcos]
12:45:56 [marcos]
12:45:57 [marcos]
12:45:57 [marcos]
12:46:23 [Norm]
...It shouldn't be able to be remotely readable. It's a privacy violation if you can see what else is running.
12:46:37 [Norm]
NM: You could just name them 1, 2, 3, 4,...
12:46:46 [Norm]
timeless: Without using those particular numbers.
12:46:51 [Norm]
DanC: Where do widget: get resolved?
12:47:02 [Norm]
timeless: In the DOM, where source must be resolvable.
12:47:05 [Norm]
12:47:18 [Norm]
timeless: For example, in img.src.
12:47:23 [Norm]
DanC: No one ever writes these things down?
12:47:37 [Norm]
timeless: You could, but it won't work.
12:47:40 [MikeSmith]
12:48:15 [Norm]
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.
12:48:31 [Norm]
...But if you never expect them to be written down, you could pick a more obscure name.
12:48:56 [Norm]
???: These things might one day appear in other spaces.
12:49:56 [timeless]
ABe: if MC would put dashboard back up
12:50:03 [Norm]
scribenick: timeless
12:50:03 [timeless]
... the only potential i see for this to leak out
12:50:05 [MikeSmith]
browser architecture in general also suggests that things leak out (e.g., from XUL into gecko core)
12:50:13 [anne]
anne has joined #wam
12:50:15 [timeless]
ABe: is a bizarre use case
12:50:24 [timeless]
... as you can see he has two clock instances
12:50:34 [DanC_lap]
ack danc
12:50:34 [Zakim]
DanC_lap, you wanted to ask where widget: URIs typically occur
12:50:47 [timeless]
... The possibility would be if you could package a skin for widgets
12:50:55 [DanC_lap]
q+ to ask about js a la: if img.src = "widget://..."
12:51:32 [DanC_lap]
ack danc
12:51:32 [Zakim]
DanC_lap, you wanted to ask about js a la: if img.src = "widget://..."
12:52:19 [timeless]
MC: as you can see this leaks the full path
12:52:38 [timeless]
... the security model of these applications is not equivalent to file:
12:52:53 [timeless]
... per the package resource you must specify which privileges you need.
12:53:06 [timeless]
... e.g. network=true|false
12:53:12 [timeless]
... plugins=true|false
12:53:19 [timeless]
... and additional features
12:53:37 [timeless]
... and we have a seperate policy language to control what is actually allowed
12:53:57 [timeless]
Noah: so you guys are attacking the software installation problem
12:53:59 [timeless]
MC: yes
12:54:12 [DanC_lap]
s/Noah: so/DanC: so/
12:54:57 [timeless]
DanC: the slide layout changed for http
12:55:09 [timeless]
MC: no, i wasn't comparing the protocols against them
12:55:18 [timeless]
... I was hoping through the magic of transitions, you'd be convinced
12:55:31 [timeless]
... At this point we're open to anything
12:55:42 [timeless]
... But we see a lot of problems with http
12:56:04 [timeless]
DanC: you're certainly changing the software implementation of http
12:56:16 [timeless]
MC: there are going to be hundreds of things we'd have to say you can't do
12:56:20 [timeless]
with http
12:56:35 [timeless]
... in terms of defining response codes.
12:56:55 [timeless]
Noah: to me what's going to be harder
12:57:05 [timeless]
... the problem might be that when you do an http request
12:57:18 [timeless]
... for some cases you're going to want to do a real http request
12:57:24 [timeless]
... and some cases you won't.
12:57:40 [DanC_lap]
(I would use "subtle" where he used complex on the slide, but the point is pretty much the same)
12:58:23 [timeless]
MC: even the overhead of adding the overhead of http is code+weight
12:58:57 [timeless]
Noah: it's still very light as protocols.
12:59:08 [timeless]
DanC: did the requirements list the details?
12:59:22 [Norm]
scribenick: Norm
12:59:33 [DanC_lap]
s/details/security policy, e.g. same origin, details/
12:59:37 [Norm]
timeless: So, one of the things that widgets will do is ask for access to HTTP
12:59:51 [Norm]
...So they might call home and do work with their well known server, and probably only that server
13:00:05 [DanC_lap]
q+ to ask about the state of deployment
13:00:07 [Norm]
...There's a bugzilla appilication that does caching and it would be nice if I could use it for any bugzilla.
13:00:30 [Norm]
...It's just a widget I've installed (purchased actually, there's a real vendor for this).
13:01:08 [Norm]
...It's a bugzilla UI, but it has no relation to the code for the standard bugzilla UI
13:01:21 [Norm]
...One of the things we've prioritized is "Networked: true or false?"
13:01:51 [DanC_lap]
q+ to explore the "implementation defined" proposal (e.g. run-time generated nonce scheme name)
13:02:05 [Norm]
...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
13:02:38 [MikeSmith]
ArtB: ↑
13:02:57 [Norm]
ABe: Reusing http: introduces ambiguity, is a pointer into the widget or a pointer to a resource on the "real"
13:03:00 [Norm]
13:03:12 [Norm]
ABe: This is especially the case now that TLD has gone away.
13:03:42 [Norm]
Noah: Is this really a collision? What two things have the same name accidentally.
13:03:57 [Norm]
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.
13:04:09 [Norm]
ABe: Then there's the problem of the signed package.
13:04:26 [Norm]
scribenick: timeless
13:04:38 [timeless]
Noah: usually a signature is an invariant
13:04:50 [timeless]
MC: when a signature changes, what do you do then?
13:04:54 [timeless]
AB: time check
13:05:10 [hsivonen]
hsivonen has joined #wam
13:05:31 [timeless]
MC: implementation detail...
13:05:52 [timeless]
... (Slide)
13:06:51 [timeless]
... hopefully i've proven to you that apple's solution of using file is a privacy issue and security risk
13:06:52 [DanC_lap]
(ah... so "implementation detail" doesn't prohibit file:)
13:07:19 [timeless]
... I don't see leaving it as an implentation detail is an actual option
13:07:21 [DanC_lap]
ack danc
13:07:21 [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)
13:08:18 [Norm]
DanC: Why not just make up the scheme names on the fly?
13:08:39 [Norm]
timeless: Scheme names can be added on the fly, after the application starts to run, so there would be the possibility of collision.
13:09:06 [timeless]
JS: ok
13:09:21 [timeless]
MC: we need to consider extensibility of the uri scheme
13:09:43 [timeless]
Noah: the design considerations are going to be very different in two instances
13:09:49 [DanC_lap]
DanC: I'd sure like to hear a consistent answer about whether these are internal-only names or not.
13:09:59 [Benoit]
Benoit has joined #wam
13:10:24 [timeless]
Noah: make a decision about if it leaks out
13:10:34 [timeless]
... it feels wrong to design something hoping it doesn't leak out.
13:11:02 [Norm]
JS: One possibility, though not likely, imagine that I make a game where you click on the right or the left image.
13:11:20 [Norm]
...If I store that in a preference (or maybe it's the base path of a scheme)
13:11:33 [Norm]
...I strip off just the picture name and I have the name for the theme.
13:11:39 [Norm]
s/of a scheme/of a theme/
13:11:58 [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.
13:12:04 [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. " --
13:12:23 [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.
13:12:35 [Norm]
DanC: So that's a pretty clear answer: these aren't just for a single, running instance
13:12:55 [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.
13:13:14 [timeless]
Noah: it seems like you are exposing two things
13:13:28 [DanC_lap]
q+ to ask about guuids in widget: uris
13:13:43 [timeless]
... it seems like you're offering to have a management policy which shows groups of related instances
13:14:02 [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.
13:14:21 [Norm]
...Suppose it's like cookies, users can see related cookies. In today's scheme, the logical thing is the domain.
13:14:45 [Norm]
...As long as the widget user agent stores which widget got which random ID, it would be ok.
13:15:00 [Norm]
...Though it might be easier from an implementation perspective to split on the name instead of hashing it.
13:15:16 [DanC_lap]
ack danc
13:15:16 [Zakim]
DanC_lap, you wanted to ask about guuids in widget: uris
13:15:35 [timeless]
Danc: is widget:uuid in your current draft
13:15:41 [timeless]
MC: it was in a draft, it is no longer
13:15:48 [timeless]
DanC: have you decided in favor/against?
13:15:59 [timeless]
MC: it's an open issue
13:16:11 [timeless]
DanC: what's state of the art?
13:16:35 [timeless]
ABe: Opera 9.6 on desktop and probably base for windows mobile and sybmian
13:16:49 [timeless]
... probably uses widget and some widgetuseragent generated bit
13:17:04 [timeless]
... it's only meaningful for the device
13:17:16 [timeless]
... it also establishes a security model for accessing things
13:17:27 [timeless]
... as the browser can reuse the cross domain security module
13:18:20 [timeless]
... we're using an identifier because it's an incredibly convinently way to establish a same origin policy
13:18:29 [timeless]
DanC: and the fact that it's not easily guessable
13:18:55 [timeless]
DanC: if that it's not easily guessable is a requirement
13:19:02 [timeless]
... then that rules out domain names.
13:19:25 [timeless]
ABe: this is based on Opera's internal choices which predate the consensus (not yet established)
13:19:31 [timeless]
... of the working group
13:20:28 [timeless]
PB: Even if the unique identifier were guessed, knowing that, no widget would have any greater rights
13:20:43 [timeless]
... the hard to guess requirement comes from privacy,
13:20:50 [timeless]
... number of installed entities.
13:21:33 [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.)
13:21:34 [timeless]
MC: the runtime will still block widget accessing other widgets because of identifier/origin crossing
13:23:43 [timeless]
JS: MC "instantiated a new instance of the clock widget"
13:23:58 [timeless]
ABe: currently that on Opera desktop involves downloading another instance
13:24:11 [timeless]
MC: I believe Apple downloads it again
13:24:36 [timeless]
BS: For windows, there's one on disk image and two memory instances.
13:25:09 [timeless]
ABe: whether instantiation involves by copying on disk or not is an implementation detail
13:25:21 [timeless]
... which doesn't affect the discussion at any point.
13:25:42 [timeless]
MC: TAG: do you feel we have enough grounds for a new uri scheme?
13:25:54 [timeless]
... if not, what do we need to do?
13:26:16 [timeless]
DanC: you need to establish the right requirements
13:26:27 [timeless]
AB: I agree we need to flesh out the requirements
13:26:51 [timeless]
... I think they're in the points MC listed but not fleshed out
13:27:12 [DanC_lap]
(ArtB, is that in the requirements document?)
13:27:18 [timeless]
Noah: I think you need to establish for all time whether things leak out
13:27:44 [timeless]
JS: requirements doc is
13:28:01 [timeless]
13:28:24 [timeless]
Noah: if you think they're going to leak out....
13:28:32 [timeless]
... I would really look at the registry issues.
13:28:57 [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.
13:29:16 [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.
13:29:35 [timeless]
MC: is there a precedent for a readonly server
13:29:49 [timeless]
DanC: i think debian servers
13:30:00 [DanC_lap]
s/debian servers/debian package names/
13:30:20 [DanC_lap]
(debian package names are, in a way, grounded in http names)
13:31:22 [timeless]
MC: has someone written a spec which defined using readonly
13:31:40 [timeless]
DanC: TimBL asked the python people to make uris
13:31:53 [timeless]
Noah: has anyone gone to the browser people
13:32:30 [timeless]
... to make a complicated proxy hack for http
13:32:56 [DanC_lap]
s/make uris/make python package names into http uris/
13:33:04 [timeless]
MC: hsivonen of mozilla explained that it would be hard and cause conflicts.
13:33:27 [timeless]
AB: where do we do follow up? www-tag?
13:33:39 [timeless]
DanC: yes
13:33:46 [timeless]
... what's the time scale?
13:33:56 [timeless]
MC: we want to finish this within 3 months.
13:34:06 [timeless]
DanC: are there any test cases for this?
13:34:22 [timeless]
MC: no
13:34:41 [timeless]
... we're starting an implementation now
13:34:48 [timeless]
AB: coffee break
13:35:26 [DanC_lap]
(I might have some more precedent bookmarked under "software installation" on delicious; network isn't happy. :-/)
13:35:35 [ArtB]
rrsagent, make minutes
13:35:35 [RRSAgent]
I have made the request to generate ArtB
13:37:52 [Benoit]
Benoit has joined #wam
13:39:33 [hlee7]
hlee7 has joined #wam
13:39:48 [hlee7]
14:11:34 [tlr]
tlr has joined #wam
14:16:00 [claudio]
claudio has joined #wam
14:23:49 [marcos]
zakim, pick a victim
14:23:49 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Iles_A
14:23:53 [stefanocrosta]
stefanocrosta has joined #wam
14:24:04 [ArtB]
Chair: ArtB
14:24:18 [marcos]
zakim, pick a victim
14:24:18 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Iles_A
14:24:29 [marcos]
chairnick: Artb
14:24:38 [marcos]
chair: Artb
14:24:43 [marcos]
zakim, pick a victim
14:24:43 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Iles_A
14:25:12 [marcos]
zakim, pick another viction
14:25:12 [Zakim]
I don't understand 'pick another viction', marcos
14:25:26 [marcos]
zakim, pick another victim
14:25:26 [Zakim]
I don't understand 'pick another victim', marcos
14:27:04 [ArtB]
Topic: Section 8.2, Step #11 - Need to describe what happens if the widget already exists
14:27:20 [ArtB]
14:28:07 [Norm]
Norm has joined #wam
14:28:15 [ArtB]
AB: if widget already exists, what do we do?
14:28:19 [shepazu]
shepazu has joined #wam
14:28:21 [ArtB]
ABe: what do other impls do?
14:28:41 [ArtB]
MC: Dashboard says "widget exists, do you want to override it?"
14:29:09 [Norm]
Norm has left #wam
14:29:33 [ArtB]
JS: not sure I understand why this is in Step 11
14:29:45 [ArtB]
MC: agree, it's not really related to Step 11
14:29:57 [ArtB]
... but the issue needs to be addressed
14:30:25 [ArtB]
JS: so the same widget cannot be installed more than once?
14:30:30 [ArtB]
MC: that's correct
14:30:40 [ArtB]
BS: is this based on file name?
14:30:45 [ArtB]
MC: no it isn't
14:30:56 [ArtB]
... it is based on something internal
14:31:08 [ArtB]
ABe: probably some id
14:31:19 [ArtB]
ABe: this should probably be an impl detail
14:31:23 [ArtB]
BS: not sure I agree
14:31:40 [ArtB]
... for Vista, it's based on file name
14:33:28 [ArtB]
MC: On Dashboard, uses identifier in the plist file
14:33:41 [ArtB]
AB: I tend to agree this should be an implementation detail
14:33:48 [ArtB]
... Let the UA decide what to do
14:34:00 [ArtB]
... Could also reflect a user preference
14:35:05 [ArtB]
[ Marcos does some experimenting with Dashboard ... ]
14:36:50 [hendry]
Opera 9.6 allows the same widget to be installed multiple times
14:37:25 [ArtB]
Present+ Kai_Hendry
14:38:57 [ArtB]
MC: either it is an impl detail or we specify it :-)
14:39:46 [ArtB]
MC: we need to specify something regarding update
14:40:24 [ArtB]
... versus installing a second widget with the same name/id as a previously installed widget
14:43:57 [ArtB]
MC: part of the problem is that the config file is optional
14:44:15 [arve]
arve has joined #wam
14:44:32 [ArtB]
PB: such a widget can never be considered identical to another widget
14:46:18 [ArtB]
[ Marcos enumerates the various scenarios ]
14:46:35 [ArtB]
... 1. If no config file, they are treated as unique
14:47:51 [ArtB]
... 2. If config file, but no id attr, then they are treated as unique
14:48:07 [ArtB]
... 3. If config has an id attr, and id is the same on both, they are the same widget
14:49:53 [ArtB]
see update spec)
14:53:28 [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
14:53:42 [ArtB]
... per the Updates spec
14:53:49 [paddy]
MIDP spec relating to ugrade procedure:
14:54:38 [hendry]
apt-get remove --purge package && apt-get install package
14:54:53 [hendry]
(how Debian works)
14:55:10 [ArtB]
JS: users don't want to have any of their data removed during update
14:55:54 [ArtB]
... can always do some data pruning after the update is running
14:56:37 [Benoit]
Benoit has joined #wam
14:58:01 [ArtB]
PB: Java have some conventions we can consider
14:58:06 [marcos]
marcos has joined #wam
14:58:55 [ArtB]
MC: we've discussed comparing versions before
15:00:25 [ArtB]
JS: can also take a look at what Mozilla has done
15:00:44 [ArtB]
... the application decides what to do
15:01:31 [hendry]
debian version ref:
15:02:31 [ArtB]
MC: I've already looked at some various practices
15:02:45 [ArtB]
... We could recommend a rollback mechanism
15:04:01 [ArtB]
[ Marcos displays MIDP 2.0's versioning mechanism ... ]
15:04:23 [ArtB]
MC: is 1.02 < or > than 1.002?
15:04:31 [ArtB]
PB: can't do 1.002
15:05:01 [Zakim]
disconnecting the lone participant, Iles_A, in IA_WebApps(Widgets)3:00AM
15:05:04 [Zakim]
IA_WebApps(Widgets)3:00AM has ended
15:05:05 [Zakim]
Attendees were Josh_Soref, Mike, Iles_A
15:05:09 [hendry] old version string discussion
15:05:14 [ArtB]
... limited to two decimals per number
15:05:50 [ArtB]
ABe: what about one widget with more than one branding?
15:08:27 [ArtB]
AB: I don't think we are getting consensus on this issue
15:09:23 [ArtB]
MC: propose we leave the current model but recommend using MIDP model
15:09:47 [ArtB]
PB: besides version number, we still have the original issue
15:11:19 [ArtB]
MC: propose we recommend authors use MIDP model for versioning
15:11:55 [timeless]
for the record,
15:13:00 [ArtB]
ACTION: Marcos will create the text and processing model to codify the four conditions enumerated above
15:13:00 [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].
15:13:48 [ArtB]
ACTION: Marcos will create text to address the version string issue by recommending MIDP 2.0 model
15:13:48 [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].
15:15:50 [ArtB]
AB: We do need to careful about copyright issues
15:16:21 [ArtB]
MC: I will create text that is "inspired by" the Java doc but will not copy it
15:16:58 [ArtB]
Topic: Section 9.1 locating thumbnails
15:17:28 [ArtB]
MC: it is a duplicate of the finding the icons issue
15:17:35 [ArtB]
... We don't need to discuss it
15:19:17 [ArtB]
AB: Meeting Adjourned for today
15:19:26 [ArtB]
RRSAgent, make minutes
15:19:26 [RRSAgent]
I have made the request to generate ArtB
15:19:41 [ArtB]
zakim, bye
15:19:41 [Zakim]
Zakim has left #wam
15:22:47 [ArtB]
RRSAgent, bye
15:22:47 [RRSAgent]
I see 7 open action items saved in :
15:22:47 [RRSAgent]
ACTION: Barstow see if the W3C systeam/webreq can help with a conformance checker [1]
15:22:47 [RRSAgent]
recorded in
15:22:47 [RRSAgent]
ACTION: Macros move the version string section from P&C spec to the Updates spec [2]
15:22:47 [RRSAgent]
recorded in
15:22:47 [RRSAgent]
ACTION: Marcos move the version string section from P&C spec to the Updates spec [3]
15:22:47 [RRSAgent]
recorded in
15:22:47 [RRSAgent]
ACTION: Barstow determine the status of URI Template RFC and report back to WG [4]
15:22:47 [RRSAgent]
recorded in
15:22:47 [RRSAgent]
ACTION: Marcos send Widget URI scheme slides to one of {member,public}-webapps [5]
15:22:47 [RRSAgent]
recorded in
15:22:47 [RRSAgent]
ACTION: Marcos will create the text and processing model to codify the four conditions enumerated above [6]
15:22:47 [RRSAgent]
recorded in
15:22:47 [RRSAgent]
ACTION: Marcos will create text to address the version string issue by recommending MIDP 2.0 model [7]
15:22:47 [RRSAgent]
recorded in