17:07:37 <RRSAgent> RRSAgent has joined #wam
17:07:37 <RRSAgent> logging to http://www.w3.org/2009/11/02-wam-irc
17:07:46 <ArtB> RRSAgent, make log Public
17:08:03 <ArtB> Meeting: Widgets F2F Meeting in Santa Clara CA US
17:08:08 <ArtB> Date: 2 November 2009
17:08:12 <ArtB> Chair: Art
17:08:19 <ArtB> ScribeNick: ArtB
17:08:23 <ArtB> Scribe: Art
17:08:34 <ArtB> Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday.2C_November_2
17:08:48 <ArtB> Present: Art, Marcos, Benoit, Magnus
17:09:41 <Magnus> Magnus has joined #wam
17:10:10 <ArtB> Topic: Agenda Review
17:10:15 <ArtB> AB: Agenda is http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday.2C_November_2
17:10:24 <ArtB> AB: any change requests?
17:10:38 <ArtB> AB: the agenda includes some specs that will not be on the agenda
17:10:47 <ArtB> BS: when does widgets meet with DAP?
17:10:59 <ArtB> AB: today 15:30-16:30
17:12:12 <ArtB> BS: on a recent call, we talked about widgets and html5 and caching
17:12:20 <ArtB> ... think this is something we need to state
17:12:33 <ArtB> ... eg where do we define that
17:12:47 <ArtB> ... we don't have to take it now but should figure out who are the right people to chat
17:13:21 <ArtB> AB: can you take an action to define the problem statement?
17:13:31 <ArtB> BS: I'm not that familiar with that subject
17:13:42 <ArtB> MC: I think the topic is well known
17:14:03 <ArtB> BS: but has the interaction been stated or defined?
17:14:09 <ArtB> MC: they just work together
17:15:26 <ArtB> AB: I think we need to differentiate overlapping specs and synergistic usage of HTML5 specs
17:15:48 <ArtB> MC: we don't create overlapping specs with HTML5
17:16:07 <ArtB> AB: how do we want to handle this?
17:16:17 <ArtB> ... put it on the agenda of a VC?
17:16:23 <ArtB> MC: I think we've talked about this before
17:16:36 <ArtB> ... we can talk about App Cache's uses by widgets
17:17:21 <ArtB> AB: on the way to SFO I created http://www.w3.org/2008/webapps/wiki/Coordination
17:17:22 <timeless> if a wua is online and doesn't offer caching, will the widget author complain?
17:17:34 <ArtB> ... this is intended to capture various "coordination points"
17:17:54 <JereK> JereK has joined #wam
17:17:56 <Benoit> Benoit has joined #wam
17:18:28 <Marcos> http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets#Monday.2C_November_2
17:25:05 <ArtB> [ Art adds a new "Widgets and HTML5" section to the Coordination wiki ]
17:26:56 <ArtB> MO: what about HTML4
17:27:21 <ArtB> MC: we have a dependency on some parts of HTML5
17:28:15 <ArtB> MO: at least one of the widgets specs references an HTML5 spec
17:28:23 <ArtB> MC: yes, the TWI spec references Web Storage
17:29:06 <ArtB> ... it does mean we can't progress to REC until Web Storage is more mature
17:29:56 <ArtB> AB: re plans, I added a new Plans column to our PubStatus page http://www.w3.org/2008/webapps/wiki/PubStatus
17:30:05 <Benoit> great
17:30:16 <ArtB> ... this provides useful data to the WG and the Public
17:30:47 <ArtB> ... my expectation is that by the end of the day tomorrow, the Plans will have the best data we have for each of WebApps specs
17:33:20 <ArtB> AB: Hixie told me a week or so ago he expects Web Storage to be ready for LC in November
17:33:35 <ArtB> ... I believe that spec already has a number of impls
17:34:02 <ArtB> MC: that was true but isn't so any more given the new Structured Clones stuff that has been added
17:34:22 <ArtB> ... with structued clones can now store more complex structues
17:34:31 <ArtB> ... and it has no serialization syntax
17:35:02 <ArtB> AB: we will discuss TWI spec tomorrow morn for 1.5 hours
17:35:24 <ArtB> ... we should add Web Storage status and related discussions
17:36:02 <ArtB> AB: I'm not convinced we must have that dependency on Web Storage
17:36:16 <ArtB> ... apparently Opera thinks otherwise
17:36:20 <ArtB> MC: yes, that's true
17:39:05 <ArtB> Topic: Widget URIs
17:39:22 <ArtB> AB: we decided not to include this spec on this week's agenda for a couple of reasons:
17:39:27 <Benoit> http://dev.w3.org/2006/waf/widgets-uri/
17:39:34 <ArtB> ... 1. the LC comment period doesn't end until Nov 10
17:40:00 <ArtB> ... 2. the Editor, Robin Berjon, is Chairing the DAP WG meeting on Nov 2-3
17:40:22 <ArtB> ... 3. We discused this during our Oct 29 weekly call and Robin stated he would look for Larry this week
17:40:40 <ArtB> Present+ Larry
17:40:48 <ArtB> LM: does anyone have any comments
17:40:56 <ArtB> AB: this is a great idea 
17:41:26 <ArtB> ... I'm expect more comments and wanted to queue them up to take them all at once
17:41:34 <ArtB> LM: my comments aren't from the TAG
17:41:46 <ArtB> ... want to know if it meets the guidelines for a new scheme
17:41:55 <ArtB> MC: I share some of your concernts
17:42:03 <ArtB> s/concernts/concerns/
17:43:03 <ArtB> AB: I'm OK with talking about it but it's highly likely the conversation will need to be replayed when Robin is available
17:43:31 <ArtB> ... I too am concerned about whether or not we've reached the threshold where a new scheme is needed
17:43:48 <ArtB> LM: there is no scheme that works as is
17:44:04 <ArtB> ... I don't think the new scheme issue is so great
17:44:22 <ArtB> ... although for some TAG members it is
17:44:30 <ArtB> ... need to think about authority
17:44:46 <ArtB> ... there are some things like authority that must be tightened
17:45:02 <ArtB> ... that leads to security issues
17:46:24 <ArtB> MC: we have ZIP relative paths
17:46:47 <ArtB> LM: need to look at it from the view of is it really going to work
17:47:24 <anne> anne has left #wam
17:47:30 <ArtB> RRSAgent, make minutes
17:47:30 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-wam-minutes.html ArtB
17:47:54 <anne> anne has joined #wam
17:50:48 <ArtB> MC: we don't control the ZIP spec
17:50:58 <ArtB> ... we do try to clarify it
17:51:04 <ArtB> LM: can profile it
17:51:25 <ArtB> ... W3C doesn't have to support every feature of ZIP
17:52:46 <ArtB> ... ease of impl should not take priority over interoperability
17:53:14 <arve> arve has joined #wam
17:53:18 <ArtB> MC: the P+C spec defines the Zip relative path
17:53:45 <ArtB> LM: who is the audience for the URI scheme?
17:53:56 <ArtB> MC: supposed to be private to the widget instance
17:54:05 <ArtB> LM: so then, why do you need it?
17:54:20 <ArtB> MC: one reason is because we don't want people to use file:
17:54:28 <ArtB> LM: that's not a good reason
17:54:45 <ArtB> ... if you have real interop problem that's one thing
17:59:39 <ArtB> Present+ Josh
18:01:25 <timeless_mbp> timeless_mbp has joined #wam
18:03:55 <tlr> tlr has joined #wam
18:04:11 <ArtB> Topic: Packaging and Configuration Spec
18:05:48 <ArtB> AB: MC and MH have been debating valid Zip relative path  for some time now
18:05:58 <ArtB> ... want to get consensus here if there is an issue or not
18:07:06 <ArtB> ... we should not publish LCs if we have open issues
18:08:47 <ArtB> MC: let's look at the e-mail ...
18:10:31 <ArtB> AB: here's the last email from MH: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0305.html
18:11:08 <ArtB> MC: I don't think there is an issue
18:12:55 <Marcos> http://dev.w3.org/2006/waf/widgets/#rule-for-identifying-the-media-type-of-a
18:14:36 <ArtB> [ We look at section 9.1.10 of LC#3 ]
18:14:52 <ArtB> JS: please make sure the Examples use the same amount of indentation
18:16:17 <timeless_mbp> example: .topos.db is a SQLite format 3 binary file
18:17:07 <timeless_mbp> .knips.xml
18:19:37 <timeless_mbp> but ... those should be .db and .xml
18:20:28 <Marcos> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0299.html
18:22:44 <ArtB> JS: not sure basename is a good tool to use here
18:23:01 <ArtB> ... in terms of helping us understand what the spec should say
18:23:15 <timeless_mbp> in test/.jpg => "test/" is a directory path
18:23:42 <timeless_mbp> basename's job is to by default strip out directory components from a path to a file
18:23:49 <timeless_mbp> yielding simply the filename portion of the path
18:24:14 <ArtB> MC: perhaps we should have sent everything to sniff and not do the optimizations
18:24:22 <marcin2> is it ok to come now?
18:24:25 <timeless_mbp> yes
18:24:27 <ArtB> ... we added this as a request from Mozilla
18:24:33 <timeless_mbp> the second argument to basename is for telling basename what extra thing to strip from the filename
18:24:35 <ArtB> AB: was that Henri?
18:24:42 <ArtB> MC: yes Henri and perhaps Jonas too
18:24:59 <ArtB> MC: I think the algorithm we defined is OK
18:25:08 <ArtB> ... we've gone thru the cases
18:25:19 <ArtB> MC: are you OK with this JS?
18:25:34 <ArtB> JS: yes, it seems OK 
18:27:02 <ArtB> Present+ Marcin
18:27:17 <ArtB> MH: I'm OK with dot something is a file
18:27:26 <ArtB> ... think the Proc Model needs to be changed
18:28:03 <ArtB> ... we don't need ranges 
18:28:13 <timeless_mbp> If any character in the extension is outside the U+0041-U+005A range and the U+0061-U+007A range, then go to step 10 in this algorithm.
18:28:21 <timeless_mbp> For example, if the extension is ".pñg", the go to step 10 in this algorithm.
18:29:47 <timeless_mbp> 10 = #
18:29:47 <timeless_mbp> Let content-type be the result of processing file through the [SNIFF] specification.
18:29:51 <timeless_mbp> 11 = # Return the value of content-type.
18:30:09 <timeless_mbp> note that the current specification ended up w/ bullets instead of numbers which caused us problems :(
18:30:15 <ArtB> MH: we don't need the ranges
18:30:18 <ArtB> MC: why not?
18:30:31 <ArtB> MH: won't be able to create test cases for this
18:30:39 <ArtB> MC: yeah, I guess that's true
18:30:50 <ArtB> ... it is an optimazation so it could be removed
18:31:03 <ArtB> s/optimazation/optimization/
18:31:14 <ArtB> MH: can case-insensitively match
18:31:20 <ArtB> MC: yes, can do it that way
18:31:36 <ArtB> ... yes, I guess this can be viewed as over-specified
18:31:42 <ArtB> ... I don't see any harm
18:32:09 <ArtB> ... that is no harm, in keeping it
18:32:37 <ArtB> MH: but we don't need it
18:33:11 <ArtB> AB: we will need to think about its affect on the impl
18:33:38 <ArtB> AB: can you MC live with removing it?
18:34:10 <Magnus> Magnus has joined #wam
18:34:25 <ArtB> ... I would prefer to err on the side of simplicity i.e. to remove it
18:34:53 <ArtB> MC: if we remove it, it will not affect implementations because it is an optimization
18:36:25 <ArtB> JS: in fact we are defining case-insensitive
18:37:07 <ArtB> MC: this algorithm is just to match the table of ~10 extensions
18:37:33 <ArtB> MH: sniff has another table for extensions
18:37:58 <ArtB> ... we typically have UTF-8
18:38:15 <ArtB> JS: case insensitive is not well-defined
18:38:54 <ArtB> ... should clarify why the A, B, C and examples are in the spec
18:39:11 <ArtB> MH: is case sensitive defined in Unicode
18:39:40 <Marcos> http://unicode.org/reports/tr10/
18:39:45 <ArtB> MC: its complex; see Unicode Collision Alg
18:40:28 <ArtB> AB: so we are now saying the text will remain but clarified i.e. why those sub-steps are there?
18:40:31 <ArtB> MC: yes
18:40:37 <ArtB> MH: can you live with that?
18:40:53 <ArtB> s/MH: can you/AB: MH, can you/
18:41:02 <ArtB> MH: yes, if the text is clarified
18:41:26 <ArtB> AB: MC, what have you changed?
18:41:36 <ArtB> MC: I changed the Example between A. and B.
18:42:07 <timeless_mbp> This would probably be implemented by scanning the filename from right to left searching for non-ascii or <ascii-period>. at the first instance of non-ascii, bail
18:42:25 <Marcos> The above step is precisely here to handle case comparison for file extensions such as ".pñg". 
18:42:47 <ArtB> AB: if we get consensus on this issue, I want to record a Resolution
18:43:21 <ArtB> AB: any objections to the text MC proposes above?
18:43:36 <ArtB> JS: need to be careful where it is inserted
18:44:04 <ArtB> AB: any objections?
18:44:07 <ArtB> [ None ]
18:44:41 <ArtB> RESOLUTION: the text MC proposes above addresses the issue MH had re the extension algorithm
18:44:54 <ArtB> RRSAgent, make minutes
18:44:54 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-wam-minutes.html ArtB
18:58:13 <Lachy> Lachy has joined #wam
19:00:52 <Benoit> Benoit has joined #wam
19:01:15 <tlr_> tlr_ has joined #wam
19:03:22 <darobin> darobin has joined #wam
19:08:43 <shepazu> shepazu has joined #wam
19:15:28 <mmielke> mmielke has joined #wam
19:22:38 <tlr__> tlr__ has joined #wam
19:22:59 <Marcos> Marcos has joined #wam
19:24:51 <tlr> tlr has joined #wam
19:29:06 <Benoit> Benoit has joined #wam
19:30:58 <Benoit> Benoit has joined #wam
20:25:36 <timeless_mbp> timeless_mbp has joined #wam
20:51:21 <Marcos> Marcos has joined #wam
20:52:12 <Marcos> Marcos has joined #wam
21:38:50 <timeless_mbp> timeless_mbp has joined #wam
21:46:00 <Marcos> Marcos has joined #wam
21:48:30 <shepazu> shepazu has joined #wam
22:01:52 <darobin> darobin has joined #wam
22:02:24 <ArtB> ArtB has joined #wam
22:02:35 <chaals> chaals has joined #wam
22:04:44 <Marcos> Marcos has joined #wam
22:04:55 <Magnus> Magnus has joined #wam
22:05:27 <timeless_mbp> timeless_mbp has joined #wam
22:10:27 <tlr> tlr has joined #wam
22:10:44 <marcin> marcin has joined #wam
22:16:34 <ArtB> ArtB has joined #wam
22:23:35 <Marcos> Marcos has joined #wam
22:25:20 <mmielke> mmielke has joined #wam
22:29:30 <timeless_mbp> timeless_mbp has joined #wam
22:31:09 <Magnus> leave
22:31:22 <Magnus> Magnus has left #wam
22:34:32 <Marcos> Marcos has joined #wam
23:01:37 <drogersuk> drogersuk has joined #wam
23:27:06 <Marcos> Marcos has joined #wam
23:35:42 <darobin> darobin has joined #wam
23:35:48 <ArtB> ArtB has joined #wam
23:42:03 <marcin> marcin has joined #wam