Re: I18N issue: case-sensitivity of locale subdirectories

[Jonas Sicking]

On Wed, Apr 29, 2009 at 7:16 AM, Robin Berjon  wrote:
> Hi,
>
> the following issue has cropped up in the I18N model as described in the
> excellent I18N document from Marcos[0].
>
> Assume we have two localisation subdirectories:
>
>  locales/en/
>  locales/EN/
>
> What happens? BCP47 (which we reference) is defined to be case-insensitive
> so it doesn't help us much in this respect.
>
> There are multiple options:
>
>  a) we define a canonical casing and all others are ignored;
>  b) we select an order of priority and we only consider one (the first to
> match);
>  c) we select an order of priority and we merge them all (in that order,
> with a given precedence rule);
>  d) the device on which the user agent is catches fire.
>
> I think that (a) should be ruled out because as BCP47 tells us, ISO639-1
> recommends lowercase (language codes), ISO3166-1 recommends uppercase
> (country codes), and ISO15924 recommends titlecase (script codes). These are
> different, but likely to be confusing, and I don't think that developers
> should have to worry about that.
>
> I'd like to reject (d) as out of line with our design preferences.
>
> I don't have a strong opinion on this, but I do I have a preference for a
> rule based on (b): if multiple locale subdirectories have the same
> case-insensitive name, then the one that comes first in ASCII-code order
> (e.g. in order: EN, En, eN, en) is used and the others are ignored.
>
> The argument in favour of only using one is that we already have to merge
> multiple directories, and adding one merge operation for what is in all
> probability a user error seems like too much complexity for little value
> (I'm happy to be contradicted by implementers however). Picking ASCII-code
> order is based on the fact that the directory names must be ASCII here (the
> others must be discarded), and picking the first is arbitrary.

I strongly agree. (c) would add a lot of code that would likely never
be used which means is bad because dead code is always bad, and also
because if in the rare case it is actually used, it's much more likely
to be buggy.

I don't have an opinion on which of the two directories should take
priority, as long as it's one of them. I'd probably argue for using
the first in ASCII-code order since that seems the simplest to
implement, but I'm open to other suggestions.

/ Jonas

RE: [widgets] Comments to element text

[Sullivan, Bryan]

Hi Robin,
I appreciate the consensus on the required attribute. 

The duration attribute is an attempt to address the more fine-grained "needs vs 
policy" alignment that is hinted at in the "required" flag. As widget runtime 
environments are deployed with policy controls on what can be accessed (e.g. 
OMTP's BONDI), we need to figure out how to let users know as soon as possible 
in the widget lifecycle (i.e. discovery/installation/use) that a widget will 
not work unless it is allowed certain permissions in the user's device. It is 
undesirable for users to find out that a widget will not work after having gone 
through the trouble of downloading it (and maybe paying). So some expression of 
the intended behavior (or necessary permissions) of the widget is needed, more 
fine grained than simple access to an API. Alternatively, some way for the 
widget or widget source (e.g. app store) to discover the permissions that will 
apply to the widget could be provided.

However the "required" flag is at least a good step in the right direction, and 
I am OK with postponing the "duration" attribute for further discussion.

Best regards,
Bryan Sullivan | AT&T
-Original Message-
From: Robin Berjon [mailto:ro...@berjon.com] 
Sent: Thursday, April 30, 2009 7:54 AM
To: Sullivan, Bryan
Cc: public-webapps
Subject: Re: [widgets] Comments to  element text

Hi Bryan,

On Apr 30, 2009, at 16:06 , Sullivan, Bryan wrote:
> Here are a couple of suggestions for the  element 
> (http://dev.w3.org/2006/waf/widgets/#the-access-element 
> ):
>
> Attributes
>
> (add two new attributes)
>
> required: Optional.
>

I'm happy to add a required attribute with the same semantics and  
processing as those of the same attribute on . I think it  
makes sense to be consistent here.

> duration: Optional.
>
> One of "one-shot", "session", "blanket", indicating the duration of  
> the access essential to the operation of the widget, and thus must  
> be allowed to the widget at runtime. In other words, the duration  
> attribute denotes the minimum period over which the widget requires  
> access to the resource, without further user action authorizing  
> continued access. Without this minimum duration the widget serves no  
> useful purpose or won't execute properly.
>

I don't think that hits the 80/20 mark. I think it's largely a UI  
decision, not something that ought to be requested by the widget  
author. For instance on the Mac I use Little Snitch, which tells me  
when any app tries to access an address and port combination that I  
haven't granted access to, and it allows me to provide access once/ 
until quit/forever. That all happens at the UI layer, it's not  
something that apps request (nor should it be as irrespective of what  
they ask the decision should rest with me, the all-powerful user).  
What's more if we add that we can add a lot of other things such as  
roaming, time of day (which can influence the price of a byte in some  
places), etc.

-- 
Robin Berjon - http://berjon.com/
 Feel like hiring me? Go to http://robineko.com/

[widget-digsig] XML Signature Properties published

[Frederick Hirsch]

from the w3c home page:

XML Signature Properties Draft Published
2009-04-30: The XML Security Working Group [1] has published a Working
Draft of XML Signature Properties [2]. This document outlines proposed
standard XML Signature Properties syntax and processing rules and an
associated namespace for these properties. The intent is these can be
composed with any version of XML Signature using the XML
SignatureProperties element. Learn more about the Security Activity
[3] . (Permalink [4] )

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

[2] http://www.w3.org/TR/2009/WD-xmldsig-properties-20090430/

[3] http://www.w3.org/Security/

[4] http://www.w3.org/News/2009#item63

regards, Frederick

Frederick Hirsch
Nokia

Re: Widget instances and widget invocations

[mozer]

Dear,
On Thu, Apr 30, 2009 at 4:45 PM, Robin Berjon  wrote:

> Hi,
>  a) the UA has somehow allowed me to pick which instance I run, I get back
> what I put for the right instance
>  b) the UA has become confused, I get both values, or something broken, or
> nothing
>  c) the UA has a single origin mapped to my widget, I get the last write


I would also add as a variant of a) (which is probalby more realistic) is
that

When you kill widget 1 it asks you if you want to save your data : Y1/N1
When you kill widget 2 it asks you if you want to save your data : Y2/N2

Then you will have Y1/Y2 --> data of 2 ; Y1/N2 --> data of 1; N1/Y2 --> data
of 2 ; N1/N2 --> previous data (or default if it was the first invocation
ever)

Then the UI may propose to the user to always save the preference and then
you will get c) behaviour

My two cents

Xmlizer

Re: [webidl] XMLHttpRequest interface object

[Boris Zbarsky]

Sam Weinig wrote:
I am not sure this always holds.  In the case of the the transition from 
the initial ("about:blank") document to a loaded document, the window 
needs to be reused at times.  Take for instance,


w = window.open("testForProperties.html");
w.customWindowProperty = "1";
w.document.customDocumentProperty = "2";

when testForProperties.html is done loading, customWindowProperty will 
still be there, but document.customDocumentProperty will not.


Yep.  In this case, that's exactly what Gecko does: puts the new 
document in the old inner window.


-Boris

Re: [webidl] XMLHttpRequest interface object

[Sam Weinig]

On Apr 30, 2009, at 9:58 AM, Ian Hickson wrote:


On Thu, 30 Apr 2009, Anne van Kesteren wrote:


For environments where the global object is represented by the Window
object XMLHttpRequest needs to be associated with a Document object  
for

determining the origin and base URL. The problem is that the
XMLHttpRequest interface object can be copied around, e.g.

 var x = frames[0].XMLHttpRequest

in that scenario x needs to be associated with Document object
associated with frames[0]. (If frames[0] is later navigated the  
Document

object would change, so it is important that this happens at this
point.)


There is a 1:1 mapping from global object to Document object now  
that we

have WindowProxy objects.

So you can probably just say something like:

  "...the Document object associated with the Window object for  
which the

  XMLHttpRequest interface object was created..."



I am not sure this always holds.  In the case of the the transition  
from the initial ("about:blank") document to a loaded document, the  
window needs to be reused at times.  Take for instance,


w = window.open("testForProperties.html");
w.customWindowProperty = "1";
w.document.customDocumentProperty = "2";

when testForProperties.html is done loading, customWindowProperty will  
still be there, but document.customDocumentProperty will not.





To be clear, assuming a and b are distinct global objects, in

 a.x = a.XMLHttpRequest
 b.x = a.x

the XMLHttpRequest interface object in b.x has a pointer to the  
Document
object associated with a. When the XMLHttpRequest constructor is  
invoked

this pointer needs to be somehow copied to the constructed object.


I think that is covered by the incantation above.

--
Ian Hickson   U+1047E) 
\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _ 
\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'-- 
(,_..'`-.;.'

Re: [webidl] XMLHttpRequest interface object

[Ian Hickson]

On Thu, 30 Apr 2009, Anne van Kesteren wrote:
>
> For environments where the global object is represented by the Window 
> object XMLHttpRequest needs to be associated with a Document object for 
> determining the origin and base URL. The problem is that the 
> XMLHttpRequest interface object can be copied around, e.g.
> 
>   var x = frames[0].XMLHttpRequest
> 
> in that scenario x needs to be associated with Document object 
> associated with frames[0]. (If frames[0] is later navigated the Document 
> object would change, so it is important that this happens at this 
> point.)

There is a 1:1 mapping from global object to Document object now that we 
have WindowProxy objects.

So you can probably just say something like:

   "...the Document object associated with the Window object for which the 
   XMLHttpRequest interface object was created..."


> To be clear, assuming a and b are distinct global objects, in
> 
>   a.x = a.XMLHttpRequest
>   b.x = a.x
> 
> the XMLHttpRequest interface object in b.x has a pointer to the Document 
> object associated with a. When the XMLHttpRequest constructor is invoked 
> this pointer needs to be somehow copied to the constructed object.

I think that is covered by the incantation above.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

I18N proposals document review...

[Phillips, Addison]

Hello Marcos,

Sorry about the delay in responding to your e-mail of the 16th [1] regarding 
the document at:

  http://dev.w3.org/2006/waf/widgets/i18n.html

Our WG had a bit of a break due to holidays, etc., so we're just now catching 
up. I realize that your WG had a desired date of the 23rd for a response from 
us. However, we're just now getting to it. We definitely will have comments for 
you.

The Internationalization WG expects to send you a complete our review during 
our next teleconference, which is scheduled for 6 May 2009. Please let me know 
if this is inconvenient for you or your WG.

Kind regards,

Addison (for I18N)

Addison Phillips
Globalization Architect -- Lab126
Chair -- W3C Internationalization WG

Internationalization is not a feature.
It is an architecture.

[1] http://lists.w3.org/Archives/Public/public-i18n-core/2009AprJun/0023.html
[2] http://www.w3.org/2009/04/29-core-minutes.html 

Re: [widgets] Comments to element text

[Robin Berjon]

Hi Bryan,

On Apr 30, 2009, at 16:06 , Sullivan, Bryan wrote:
Here are a couple of suggestions for the  element (http://dev.w3.org/2006/waf/widgets/#the-access-element 
):


Attributes

(add two new attributes)

required: Optional.



I'm happy to add a required attribute with the same semantics and  
processing as those of the same attribute on . I think it  
makes sense to be consistent here.



duration: Optional.

One of "one-shot", "session", "blanket", indicating the duration of  
the access essential to the operation of the widget, and thus must  
be allowed to the widget at runtime. In other words, the duration  
attribute denotes the minimum period over which the widget requires  
access to the resource, without further user action authorizing  
continued access. Without this minimum duration the widget serves no  
useful purpose or won't execute properly.




I don't think that hits the 80/20 mark. I think it's largely a UI  
decision, not something that ought to be requested by the widget  
author. For instance on the Mac I use Little Snitch, which tells me  
when any app tries to access an address and port combination that I  
haven't granted access to, and it allows me to provide access once/ 
until quit/forever. That all happens at the UI layer, it's not  
something that apps request (nor should it be as irrespective of what  
they ask the decision should rest with me, the all-powerful user).  
What's more if we add that we can add a lot of other things such as  
roaming, time of day (which can influence the price of a byte in some  
places), etc.


--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

[widgets] Draft Minutes from 30 April 2009 Voice Conference

[Arthur Barstow]

The draft minutes from the April 30 Widgets voice conference are  
available at the following and copied below:


   

WG Members - if you have any comments, corrections, etc., please  
sendthem to the public-webapps mail list before 7 May 2009 (the next  
Widgets voice conference); otherwise these minutes will be considered  
Approved.


-Regards, Art Barstow

   [1]W3C

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

   - DRAFT -

   Widgets Voice Conference

30 Apr 2009

   [2]Agenda

  [2] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0405.html


   See also: [3]IRC log

  [3] http://www.w3.org/2009/04/30-wam-irc

Attendees

   Present
  Art, Mike, Robin, Marcin, AndyB, Frederick, Marcos, Arve,
  Bryan, Thomas

   Regrets
  AndySledd, Mark, David

   Chair
  Art

   Scribe
  Art

Contents

 * [4]Topics
 1. [5]Review and tweak agenda
 2. [6]P&C spec:  element comments from David
 3. [7]P&C spec: L10N model
 4. [8]Security related issues with "core" Widgets specs (from
Thomas):
 5. [9]A&E spec: Per-instance Storage discussion
 6. [10]A&E spec: Comments from Rainer:
 7. [11]A&E spec: What needs to be done before publishing a
LCWD?
 8. [12]Widget URI Scheme
 * [13]Summary of Action Items
 _



fjh: none is here yet, call has not started

I'm getting "is unavailable, please try your call later"!

ScribeNick: ArtB

Scribe: Art

I'll be late

other call running over

   Date: 30 April 2009

Review and tweak agenda

   AB: draft agenda submitted 29 April
   ([14]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
   405.html). Since then Robin requested some additions
   ([15]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
   438.html) and we will add those agenda items. Any other change
   requests?

 [14] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0405.html).
 [15] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0438.html)


   [ None ]

   Topics: Announcements

   AB: June 9-11 f2f meeting is just 5 weeks away; please remember to
   register
   ([16]http://www.w3.org/2002/09/wbs/42538/WidgetsLondonJune2009/).
   Any other short annoucements?

 [16] http://www.w3.org/2002/09/wbs/42538/WidgetsLondonJune2009/).

   [ None ]

P&C spec:  element comments from David

   AB: on April 23 David submitted some comments regarding the 
   element
   ([17]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
   291.html). I haven't seen a reply. I think the gist of the comments
   is that the spec is a bit under-specified regarding what the UA will
   do with the information. Comments?
   ... David isn't present

 [17] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0291.html).


   RB: most comments are fine; I need to coordinate the text with MC
   and that should be it

   AB: I agree they seemed to make sense; think a NOT is missing in the
   4th bullet

   RB: I think the idea is the security policy takes precedence over
   the contents of the access element

   AB: so RB and MC will add text to the ED, right?

   RB: yes

   BS: I have some questions about the access element
   ... the way it is described; uses IRIs
   ... is this limited to HTTP only?
   ... what about other schemes such as FTP or UDP

   RB: any scheme that uses URIs

   BS: this element affects netwwork access by any method
   ... regardless of the scheme

   RB: yes, good point

   AB: do you understands BS' issues well enough to relfect them in the
   spec?

   RB: yes

   AB: anything else on this topic?

   BS: I will send an email about this element to the list

   AB: can you take an action to do that by May 4 at the latest?

   BS: yes

ACTION: bryan submit an email to public-webapps re the
element [recorded in
   [18]http://www.w3.org/2009/04/30-wam-minutes.html#action01]

P&C spec: L10N model

ACTION: Robin to edit access to take into account OMTP
   feedback and Bryan's [recorded in
   [19]http://www.w3.org/2009/04/30-wam-minutes.html#action02]

   AB: last week Marcos provided a short introduction to L10N model he
   proposed ([20]http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.htm),
   including his preferences for various proposals. Although some of us
   asked for Use Cases and Requirements to substantiate and clarify the
   proposals, they have not been provided. So far, preferences for the
   proposals have been submitted by at least Robin
   ([21]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
   409.html), AndyS (h

 [20] http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.htm)
 [21] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0409.html)


   So far, pref

Widget instances and widget invocations

[Robin Berjon]

Hi,

here's my quick stab at a definition:

 - multiple instances of a widget are the same widget (one  
installation) being run multiple times in parallel, e.g. a weather  
widget that you run once for the weather in Paris and once for the  
weather in Sydney;
 - multiple invocations of a widget are the same widget being run  
multiple times serially in time, which is to say that the n+1  
invocation happens after invocation n has been stopped.


The above part is for the definitions, what follows is discussion of  
some implications.


Now consider this:

 - I invoke a widget once
 - I change some preferences or effect storage somehow
 - I kill it
 - I go eat some ice-cream
 - I come back, and invoke the same widget again

In this case, I want the second invocation to have access to the same  
storage — otherwise my work is lost.


Now here's with multiple instances:

 - I invoke a widget once
 - I change some preferences or effect storage somehow
 - I invoke the same widget a second time, getting a second instance
 - I kill widget 1
 - I change some preferences or effect storage somehow in widget 2
 - I kill widget 2
 - I go eat more ice-cream
 - I come back, and invoke the widget again

What information do I get back if I look inside the storage? There are  
multiple options:


 a) the UA has somehow allowed me to pick which instance I run, I get  
back what I put for the right instance
 b) the UA has become confused, I get both values, or something  
broken, or nothing
 c) the UA has a single origin mapped to my widget, I get the last  
write


The ideal option here may be (a) but I'm unsure that it's realistic.  
Basically it would mean that the UA would have a mechanism to run an  
extra instance and to allow me to identify it (e.g. run widget as new  
profile). Would a newly created instance inherit the storage from one  
of the previous ones or a clean slate? This is getting uncomfortably  
close to a UI spec for me.


I think we agree we don't want (b).

I'm going to propose that we go with (c) — this is just like multiple  
tabs open to the same page. If a UA wants to offer a way to make a  
given instance separate (i.e. provide it with a different origin) that  
is of course fine, but IMHO it is the same problem as allowing a user  
to have different cookies in different tabs in a browser: useful, but  
not defined per spec.


--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

[widgets] Comments to element text

[Sullivan, Bryan]

Title: [widgets] Comments to  element text






Here are a couple of suggestions for the  element (http://dev.w3.org/2006/waf/widgets/#the-access-element):

Attributes

(add two new attributes)

required: Optional.

A boolean attribute that indicates whether or not this resource is essential to the operation of the widget, and thus must be accessible to the widget at runtime. In other words, the required attribute denotes that a resource is absolutely needed by the widget to function correctly, and without the availability of this resource the widget serves no useful purpose or won't execute properly. The default value when this attribute is absent is true, meaning that the resource must be made available to the widget by the widget at runtime.



duration: Optional. 

One of "one-shot", "session", "blanket", indicating the duration of the access essential to the operation of the widget, and thus must be allowed to the widget at runtime. In other words, the duration attribute denotes the minimum period over which the widget requires access to the resource, without further user action authorizing continued access. Without this minimum duration the widget serves no useful purpose or won't execute properly. 

    -   "one-shot" means that the widget requires no extended access authorization, and the runtime can prompt the user for every access attempt, if required. 

    -   "session" means that each time the widget is executed, the widget must have free access to the resource after at most one user prompt for access confirmation.

    -   "blanket" means that once the widget is installed, it requires free access to the resource without any user prompts for access confirmation. 

    The default value when this attribute is absent is "session".



Best regards,

Bryan Sullivan | AT&T

Re: [webidl] XMLHttpRequest interface object

[Anne van Kesteren]

On Thu, 30 Apr 2009 16:01:45 +0200, Anne van Kesteren  wrote:
> For environments where the global object is represented by the Window  
> object XMLHttpRequest needs to be associated with a Document object for  
> determining the origin and base URL. The problem is that the  
> XMLHttpRequest interface object can be copied around, e.g.

I didn't mean to say copied here. Rather that it can be referenced from other 
global objects.


-- 
Anne van Kesteren
http://annevankesteren.nl/

[webidl] XMLHttpRequest interface object

[Anne van Kesteren]

For environments where the global object is represented by the Window object 
XMLHttpRequest needs to be associated with a Document object for determining 
the origin and base URL. The problem is that the XMLHttpRequest interface 
object can be copied around, e.g.

  var x = frames[0].XMLHttpRequest

in that scenario x needs to be associated with Document object associated with 
frames[0]. (If frames[0] is later navigated the Document object would change, 
so it is important that this happens at this point.) To be clear, assuming a 
and b are distinct global objects, in

  a.x = a.XMLHttpRequest
  b.x = a.x

the XMLHttpRequest interface object in b.x has a pointer to the Document object 
associated with a. When the XMLHttpRequest constructor is invoked this pointer 
needs to be somehow copied to the constructed object.

What I need is some terminology in Web IDL to make this possible or a better 
solution to the problem.

(Most other APIs use the Document object associated with the script that is 
currently running for the base URL and origin and therefore do not have this 
complication.)


-- 
Anne van Kesteren
http://annevankesteren.nl/

RE: [widgets] Draft Agenda for 30 April 2009 Voice Conference

[Marcin Hanclik]

Hi Robin,

It is ok for me, if the below clarifications go into the text, into the section 
2.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, April 30, 2009 2:45 PM
To: Marcin Hanclik
Cc: Arthur Barstow; public-webapps
Subject: Re: [widgets] Draft Agenda for 30 April 2009 Voice Conference

Hi Marcin,

On Apr 30, 2009, at 14:37 , Marcin Hanclik wrote:
>>> - do we need to say anything about multiple instances of the same
>>> widget?
> I think so.
> Since widget URI is to help in inter-widget communication, I assume
> it should be clarified on the URI level as well, how different
> instances are to be handled (or not handled).
> What about e.g. inter-widget-instance communication (i.e.
> communication between two different instances of the same widget)?

The thing is: inter-widget communication is off the table for v1. I
believe that we do need to say something about multiple instances,
that is along the lines of: a widget available inside a given UA
always has the same opaque globally unique identifier, and needs to
retain the same across invocations so that origin-based decisions
work. If multiple instances of the same widget are launched
simultaneously, then they all have the same opaque globally unique
identifier. It is up to them to differentiate one from another, if
needed.

And I think that's all we need to say.

--
Robin Berjon - http://berjon.com/
 Feel like hiring me? Go to http://robineko.com/








Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is 
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or 
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by 
responding to this e-mail. Thank you.

Re: [widgets] Draft Agenda for 30 April 2009 Voice Conference

[Robin Berjon]

Hi Marcin,

On Apr 30, 2009, at 14:37 , Marcin Hanclik wrote:

- do we need to say anything about multiple instances of the same
widget?

I think so.
Since widget URI is to help in inter-widget communication, I assume  
it should be clarified on the URI level as well, how different  
instances are to be handled (or not handled).
What about e.g. inter-widget-instance communication (i.e.  
communication between two different instances of the same widget)?


The thing is: inter-widget communication is off the table for v1. I  
believe that we do need to say something about multiple instances,  
that is along the lines of: a widget available inside a given UA  
always has the same opaque globally unique identifier, and needs to  
retain the same across invocations so that origin-based decisions  
work. If multiple instances of the same widget are launched  
simultaneously, then they all have the same opaque globally unique  
identifier. It is up to them to differentiate one from another, if  
needed.


And I think that's all we need to say.

--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

RE: [widgets] Draft Agenda for 30 April 2009 Voice Conference

[Marcin Hanclik]

Hi Robin,

>>  - do we need to say anything about multiple instances of the same
>>widget?
I think so.
Since widget URI is to help in inter-widget communication, I assume it should 
be clarified on the URI level as well, how different instances are to be 
handled (or not handled).
What about e.g. inter-widget-instance communication (i.e. communication between 
two different instances of the same widget)?
Furthermore, as long as it comes to the identification of resources within a 
widget resource, we may however not want to have such a distinction.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Robin Berjon
Sent: Thursday, April 30, 2009 1:14 PM
To: Arthur Barstow
Cc: public-webapps
Subject: Re: [widgets] Draft Agenda for 30 April 2009 Voice Conference

Hi,

On Apr 29, 2009, at 16:23 , Arthur Barstow wrote:
> 1. Review and tweak agenda

I'd like to tack the following onto the agenda:

  - who volunteers to handle the the URL path to Zip relative path
mapping (and back)
  - do we need UUIDs in widget URIs
  - general review of widget URIs
  - do we need to say anything about multiple instances of the same
widget?
  - widget URI resolution to contents of a widget (as part of the L10N
model discussion)

--
Robin Berjon - http://berjon.com/
 Feel like hiring me? Go to http://robineko.com/









Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is 
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or 
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by 
responding to this e-mail. Thank you.

Re: [widgets] Draft Agenda for 30 April 2009 Voice Conference

[Robin Berjon]

Hi,

On Apr 29, 2009, at 16:23 , Arthur Barstow wrote:

1. Review and tweak agenda


I'd like to tack the following onto the agenda:

 - who volunteers to handle the the URL path to Zip relative path  
mapping (and back)

 - do we need UUIDs in widget URIs
 - general review of widget URIs
 - do we need to say anything about multiple instances of the same  
widget?
 - widget URI resolution to contents of a widget (as part of the L10N  
model discussion)


--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/

Regretts Telecon Thursday 30 April

[Andrew Sledd]

Art et al.

 

I am unable to join this afternoon's call. I submitted inputs for the
i18n/L10n Topic as per action from last week.

 

http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0436.html

 

Andy

Re: Preferences for the I18N model

[Andrew Sledd]

This message is in response to Marcos request to review 18n
proposal/discussion for widgets packaging [1]. I haven't seen any
updates or proposed updates to requirements so I'm going only from
what's in the proposal and what little has been submitted to the list.

 

Robin's email [2] answers some questions I had [3] about resource
dereferencing and resolution and proposes some additional processing
rules which I support. Namely, I support Robin's proposals for
"Dereferencing URI in configuration document" and "Finding missing
localized content".

 

My view is that for v1 we should simplify the matter; UA has one locale
and Widget content can be localized through folders, and therefore
support proposals; A2, B2

Need more info, like requirements and UC for me to support widget locale
considerations - C and D proposals.

 

Lastly, on the case sensitivity topic [4] I support the idea of one
match as proposed in b.

"b) we select an order of priority and we only consider one (the  
first to match);



b): if multiple locale subdirectories have the  
same case-insensitive name, then the one that comes first in ASCII- 
code order (e.g. in order: EN, En, eN, en) is used and the others are  
ignored."

 

Regards,

Andy Sledd

 

[1]
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0206.html

[2]
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0409.html

[3]
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0393.html

 

Re: Storage 'length' and enumeration

[Sean Hogan]

Ian Hickson wrote:

On Thu, 30 Apr 2009, Sean Hogan wrote:
  

I'm not sure about all those objects, but my (incomplete) testing of
HTML*Collections indicates that when accessed using array notation:
   object[index]; where index < object.length
they behave as a readonly array. Which has the fortuitous by-product of
allowing the object to work with Array.forEach(), etc.

Storage objects have a length property and can be accessed with array 
notation. They look like they should work with Array generic methods... 
and they do... except they aren't reliable if you use numeric keys... 
but they don't even give an error message.



They work the same way as a collection does when one of the items in a 
collection has a name that's numeric, e.g. document.images with an  
element whose name="" attribute has the value 0.


  

I would suggest one of:
1. When accessed as an array they are treated as a readonly array. i.e. MUST
use getItem(), setItem() for numeric keys
2. Treat it as an associative array. Change the name of the length property.



Storage works exactly like a collection in this respect; the values from 0 
to length-1 override the names.


  
Ok, I think you're confirming that Storage objects will work 
consistently with Array generic methods; the callback receiving a key 
into the Storage object.


I obviously haven't been following this thread accurately.