RE: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage

Hi.

I understand what you mean now.
My point of view was basically related to the APIs exposed by the "Local
Storage" and "Session Storage" interface.

=5.11.1.2 The Storage interface=

interface Storage {
  readonly attribute unsigned long length;
  [IndexGetter] DOMString key(in unsigned long index);
  [NameGetter] DOMString getItem(in DOMString key);
  [NameSetter] void setItem(in DOMString key, in DOMString data);
  [NameDeleter] void removeItem(in DOMString key);
  void clear();
};

And neither "origin" nor the "URI scheme" are actually involved in this
interface directly.
The "partitioning" of data that the usage of origin and URI scheme
ensure, it's handled internally to the implementation in our
perspective, and should not influence the Widget Developer (unless
he/she wants to).

Thanks

---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, R&D UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demarino@orange-ftgroup.com


This e-mail, and any files transmitted with it, is intended only for the
use of the person/s or entity to whom it is addressed. If you are not
the intended recipient (or authorised to receive information for the
intended recipient) you must not use, disclose, copy, print or rely on
this e-mail. If an addressing or transmission error has misdirected this
e-mail, please notify the author by replying to this e-mail and delete
all copies of this e-mail.  Thank you.

France Telecom R&D UK Ltd is a company registered in England and Wales
with company number 4193379. Our registered office is Minerva House,
Montague Close, London, SE1 9BB.

-----Original Message-----
From: Marcos Caceres [mailto:marcosscaceres@gmail.com] 
Sent: 03 February 2009 15:36
To: DE MARINO Ivan RD-ILAB-LON
Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage

The first problem is that we don't have at URI scheme for widgets.
Using http:// makes no sense for v1 because it would mean that widget
engines would also have to act as web servers (i.e., serve http headers,
etc). We want to avoid using file:// as its not formally standardized
anywhere and is not specified to support UTF-8 file names. We are
considering the tag uri scheme: http://www.taguri.org/.

The second problem is that of "origin" as defined in the HTML5 spec.
We don't have an "origin", which is "either opaque identifiers or tuples
consisting of a scheme component, a host component, a port component,
and optionally extra data." So, at the moment, not even HTML files would
work in W3C widgets because we don't have any of those (except data,
which may be the digital signature):(

Kind regards,
Marcos


On Tue, Feb 3, 2009 at 3:06 PM,  <ivan.demarino@orange-ftgroup.com>
wrote:
> Hello Marcos.
>
> What do you mean when you say:
> "one of the main barriers we have is in relation to origin and the 
> lack of a URI scheme for widgets."?
> I'm not sure I get it.
>
> Thanks
>
>
>
> ---
> Ivan De Marino
> Orange Labs
> Mobile and Web Software Engineer, R&D UK tel. +44 20 8849 5806 mob. 
> +44 7515 955 861 mob. +44 7974 156 216 
> ivan.demarino@orange-ftgroup.com
>
>
> This e-mail, and any files transmitted with it, is intended only for
the
> use of the person/s or entity to whom it is addressed. If you are not
> the intended recipient (or authorised to receive information for the
> intended recipient) you must not use, disclose, copy, print or rely on
> this e-mail. If an addressing or transmission error has misdirected
this
> e-mail, please notify the author by replying to this e-mail and delete
> all copies of this e-mail.  Thank you.
>
> France Telecom R&D UK Ltd is a company registered in England and Wales
> with company number 4193379. Our registered office is Minerva House,
> Montague Close, London, SE1 9BB.
>
> -----Original Message-----
> From: Marcos Caceres [mailto:marcosscaceres@gmail.com]
> Sent: 03 February 2009 14:41
> To: DE MARINO Ivan RD-ILAB-LON
> Cc: UDDIN Rafel RD-ILAB-LON; zze-Igloo ALI M ext RD-ILAB-LON;
> public-webapps@w3.org; linuxcoder@gmail.com
> Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
> Storage
>
> Hi Ivan, All,
>
> On Tue, Feb 3, 2009 at 11:19 AM,  <ivan.demarino@orange-ftgroup.com>
> wrote:
>> Hello.
>>
>> After some emails with Marcos Caceres we reached the conclusion that
>> part of the Specs of Widget APIs
>> (http://dev.w3.org/2006/waf/widgets-api/) overlaps/clashes with the
>> HTML5 standard draft about Key/Value Pairs Storage
>>
(http://www.whatwg.org/specs/web-apps/current-work/#structured-client-
>> si
>> de-storage).
>>
>> Our suggestion is that we should go with the HTML5 standard, removing
>> those apis the Widget API Specs, because:
>> 1) Most probably it will be supported from every browser soon anyway
>> 2) There are Open Source browsers, like WebKit, were it's already
>> finding it's space (take a look to the WebKit source code)
>> 3) It will allow developer to learn less apis for the same purpose
>> 4) They do the same thing but...
>> 5) The HTML5 draft already provides APIs for "enumeration",
"cleaning"
>> and "iteration"
>> 6) The Widget object will become more coherent, focusing on things
>> like "widget status" and "widget informations"
>> 7) The OMTP BONDI initiative itself avoided to go into the
"Persistent
>
>> Storage" aspect, because of the presence of Google (with Google
Gears)
>
>> and HTML5 Proposal, as you can see from the "BONDI Interfaces Specs"
>> at http://www.omtp.org/Bondi/PublicDraft.aspx.
>
> I've added a note in the API spec that preferences is at risk pending
> further investigation of how to implement HTML5 Storage's interface. I
> personally don't know HTML5 well enough to make an assessment on the
> viability of using this feature, so will probably need to liaise with
> members from the HTML-WG  to see how/if we can make this work.
>
> Seems that one of the main barriers we have is in relation to origin
and
> the lack of a URI scheme for widgets. I've also added space in the API
> spec for where the URI scheme for widgets should be specified. I'm
happy
> to investigate Storage by reading the HTML5 spec and liaising with the
> HTML-WG, but that won't happen for at least three weeks or more. If
> someone else wants to start investigating this and putting together a
> solid input, then by all means do so.
>
> If anyone feels strongly that we should not go down the HTML5 Storage
> route, then please speak up and provide us with a technical rationale.
>
> Kind regards,
> Marcos
> --
> Marcos Caceres
> http://datadriven.com.au
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 3 February 2009 16:28:55 UTC