Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
On Tue, Feb 17, 2009 at 2:15 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Jonas, One level of indirection is a very small price to pay for much more implementation flexibility. But like I pointed out earlier, and if I understand the problem correctly, your suggested solution will only work temporarily. It will only work until browsers implement the widget API natively, at which point you won't be able to write your own implementation of the widget API. It won't hurt developers (the methods are equivalent) and it decouples the specifications enough to support different deployment models. I agree that reusing the same API, but with a different accessor greatly reduces the hurt for developers and implementors. But it doesn't completely remove it. What (I think - correct me if I'm wrong) you've been proposing is to essentially mandate that Widgets can only work if the environment implements HTML 5; now I like HTML 5, and I think LocalStorage is great, but I don't think it should be _necessary_ to bind Widgets to HTML 5 in order for them to work - after all, using the existing draft API (based on the Apple, Nokia, and Opera APIs) they work already! So why add the restriction? Especially as what Ivan is proposing is to remove any inconsistency between the Widget Preferences and HTML 5 Storage interfaces. Well, it's not entirely what I've been proposing, although currently that might be the effect of it. I definitely agree that mandating that all of HTML5 is implemented is not a good idea. I see a few different solutions. * State in the widget specs that widget implementations need to support the localStorage API from the HTML5 spec. This can be done without requiring any other parts of HTML5 to be implemented. * Ask the HTML5 WG to break out the localStorage API into a separate spec. This might actually already be in progress, I know several things are being broken out of the HTML5 spec, and there's likely more to come. * Specify an API in the widget spec that is 100% compatible with the HTML5 API. (the last option seems like the least good since we'd have to track any changes to the HTML5 spec) / Jonas
RE: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
Hello.
Just to clearify: I never spoke about implementations.
I always spoke about interfaces to define in this Standard: adoption and
implementation is a personal step.
Neither the usage of a server side component nor a direct client side
javascript extension was in my target.
If this matter was already clear, then ignore this email ;)
...
I would propose to introduce the same kind of methods available for
HTML5 LocalStorage. Not necessarelly the same signatures, but
equivalent methods.
This means to modify slightly the widget object introducing stuff
like:
class widget {
...
long preferencesCount();
string getPreferenceKey(long index) throws
DomException.INDEX_SIZE_ERR;
string getPreference(string key);
void setPreference(string key, string value) throws
DomException.QUOTA_EXCEEDED_ERR;
void removePreference(String key);
void preferencesClear();
...
}
This ensures enumeration and some utility methods that can become
handy (like a clear and a count).
Regards
---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, RD UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@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 RD 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: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: 13 February 2009 23:44
To: Thomas Landspurg
Cc: Scott Wilson; DE MARINO Ivan RD-ILAB-LON; public-webapps@w3.org
Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage
On Fri, Feb 13, 2009 at 9:47 AM, Thomas Landspurg
thomas.landsp...@gmail.com wrote:
Hello,
I am a little bit late in the debate, but I agree with scott
proposal and arguments. Ideally the widget itself shoud not be aware
of HTML5 storage implementation, even if the widget storage API use
the same signature . And mostly because of the same need: some
architecture would require a server side implementation of the
settings instead of a client side, especially if you want to provide
the same account on different platforms.
Hmm.. i'm a bit confused. My proposal was to use a server side backend
for the .localStorage API. This would mean that there is no need to
introduce a new API.
From my understanding of the original issue that was brought up in this
thread, using a separate API rather than .localStorage would only be a
short term solution, until browsers start natively supporting the widget
API. So that does not seem like a good solution.
However it seems possible to use other solutions to implement a server
side backend for localStorage by using the callbacks defined in the
HTML5 spec.
/ Jonas
RE: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
Hello.
I'm trying to stress a bit the current implementation of preferences
storage, comparing it to the LocalStorage.
I see that a preferences array was introduced, but this araise another
problem.
A Javascript Array it's NOT a map of key/value pairs. This means
that the preferences will have to hold only the values.
This looks a bit incoeherent with the idea of having preferences
stored as key/value pairs. Doesn't it?
I would propose to introduce the same kind of methods available for
HTML5 LocalStorage. Not necessarelly the same signatures, but equivalent
methods.
This means to modify slightly the widget object introducing stuff
like:
class widget {
...
long preferencesCount();
string getPreferenceKey(long index) throws
DomException.INDEX_SIZE_ERR;
string getPreference(string key);
void setPreference(string key, string value) throws
DomException.QUOTA_EXCEEDED_ERR;
void removePreference(String key);
void preferencesClear();
...
}
This ensures enumeration and some utility methods that can become
handy (like a clear and a count).
What do you think?
Best Regards
---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, RD UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@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 RD 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: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking
Sent: 12 February 2009 19:20
To: timel...@gmail.com
Cc: Scott Wilson; public-webapps@w3.org; Ian Hickson
Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage
timeless wrote:
I think the problem here is that there's too much syntactic sugar in
sessionStorage/localStorage (this is more feedback to HTML5 or WebIDL,
and maybe Hixie or others could help to address it).
I can easily replace the object (window.sessionStorage={})
The sessionStorage property is readonly so that won't work.
but I
can't be told when my sessionStorage is decorated by a new property,
because that's not something which is available to JS (gecko has
__noSuchMethod__, but there's no watch(sessionStorage, *, feedback).
If there was a way for js objects to be told about property writes
then for the most part, they could replace a host's
sessionStorage/localStorage with their own object and do what they
need.
Today, if the HTML5 sessionStorage/localStorage objects relied on
(sugar-free) methods only, they wouldn't have a problem. -- No, I'm
not advocating this.
Things like watch points aren't really defined if they should work when
it comes to host objects I think. And if we used an API like
setProperty/getProperty they certainly would not work.
So I don't think the problem here is with the specific API localStorage
uses either. But rather with the fact that Scott is trying to deploy a
widget implementation in an environment where he is restricted about
what the APIs he is implemented are called.
I think in this instance though the problem can be worked around by
adding event listeners to the Document listening for 'storage' events.
That can be used to then save the data server-side.
/ Jonas
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
Hello,
I am a little bit late in the debate, but I agree with scott proposal and
arguments. Ideally the widget itself shoud not be aware of HTML5 storage
implementation, even if the widget storage API use the same signature . And
mostly because of the same need: some architecture would require a server
side implementation of the settings instead of a client side, especially if
you want to provide the same account on different platforms.
On Fri, Feb 13, 2009 at 6:37 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Defining equivalent methods to HTML 5 Storage - rather than mandating the
same implementation - seems like a reasonable compromise.
It would enable us to provide a consistent model for developers, while at
the same time making it more obvious how to migrate widgets and authoring
tools based on existing widget APIs, i.e.:
http://www.w3.org/TR/widgets-land/#apis
S
On 13 Feb 2009, at 16:54, ivan.demar...@orange-ftgroup.com
ivan.demar...@orange-ftgroup.com wrote:
Hello.
I'm trying to stress a bit the current implementation of preferences
storage, comparing it to the LocalStorage.
I see that a preferences array was introduced, but this araise another
problem.
A Javascript Array it's NOT a map of key/value pairs. This means
that the preferences will have to hold only the values.
This looks a bit incoeherent with the idea of having preferences
stored as key/value pairs. Doesn't it?
I would propose to introduce the same kind of methods available for
HTML5 LocalStorage. Not necessarelly the same signatures, but equivalent
methods.
This means to modify slightly the widget object introducing stuff
like:
class widget {
...
long preferencesCount();
string getPreferenceKey(long index) throws
DomException.INDEX_SIZE_ERR;
string getPreference(string key);
void setPreference(string key, string value) throws
DomException.QUOTA_EXCEEDED_ERR;
void removePreference(String key);
void preferencesClear();
...
}
This ensures enumeration and some utility methods that can become
handy (like a clear and a count).
What do you think?
Best Regards
---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, RD UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@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 RD 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: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking
Sent: 12 February 2009 19:20
To: timel...@gmail.com
Cc: Scott Wilson; public-webapps@w3.org; Ian Hickson
Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage
timeless wrote:
I think the problem here is that there's too much syntactic sugar in
sessionStorage/localStorage (this is more feedback to HTML5 or WebIDL,
and maybe Hixie or others could help to address it).
I can easily replace the object (window.sessionStorage={})
The sessionStorage property is readonly so that won't work.
but I
can't be told when my sessionStorage is decorated by a new property,
because that's not something which is available to JS (gecko has
__noSuchMethod__, but there's no watch(sessionStorage, *, feedback).
If there was a way for js objects to be told about property writes
then for the most part, they could replace a host's
sessionStorage/localStorage with their own object and do what they
need.
Today, if the HTML5 sessionStorage/localStorage objects relied on
(sugar-free) methods only, they wouldn't have a problem. -- No, I'm
not advocating this.
Things like watch points aren't really defined if they should work when
it comes to host objects I think. And if we used an API like
setProperty/getProperty they certainly would not work.
So I don't think the problem here is with the specific API localStorage
uses either. But rather with the fact that Scott is trying to deploy a
widget implementation in an environment where he is restricted about
what the APIs he is implemented are called.
I think in this instance though the problem can be worked around by
adding event listeners to the Document listening for 'storage' events.
That can be used to then save the data server-side.
/ Jonas
--
Get the ALL NEW Webwag Mobile - http://webwag.com/mobile
Thomas Landspurg - Webwag
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
On Fri, Feb 13, 2009 at 9:47 AM, Thomas Landspurg thomas.landsp...@gmail.com wrote: Hello, I am a little bit late in the debate, but I agree with scott proposal and arguments. Ideally the widget itself shoud not be aware of HTML5 storage implementation, even if the widget storage API use the same signature . And mostly because of the same need: some architecture would require a server side implementation of the settings instead of a client side, especially if you want to provide the same account on different platforms. Hmm.. i'm a bit confused. My proposal was to use a server side backend for the .localStorage API. This would mean that there is no need to introduce a new API. From my understanding of the original issue that was brought up in this thread, using a separate API rather than .localStorage would only be a short term solution, until browsers start natively supporting the widget API. So that does not seem like a good solution. However it seems possible to use other solutions to implement a server side backend for localStorage by using the callbacks defined in the HTML5 spec. / Jonas
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
Hi Jonas, We run the widgets from a server, which a web application renders into the browser window using iFrames (a typical web widget architecture). Each widget in its iFrame calls the Widget API getPref/ setPref methods, which are implemented in a locally injected JS library. This library implements the get/setPref methods as AJAX requests back to the server. If the widget used the LocalStorage interface, the server would not be engaged in the storage process, as localStorage is implemented by the browser itself. We might then run into issues where the same widget was instantiated for different users in different contexts - currently we issue an opaque identifier to each running widget instance that enables the server to keep the user preferences separate - though perhaps this could be picked up by the localStorage implementation if it used the querystring as part of calculating the storage scope. We'd still get an issue, however, of users losing all their widget preferences if they accessed them from a different device, or a different browser on the same device, which would be annoying. (Admittedly this is not an issue for single-user environments...) However we could get around this by having the Widget object return a handle for an object that implemented the HTML 5 Storage interface - in our implementation this would then be an object we define in our injected JS library (using AJAX once again), while in other implementations this could either be the localStorage instance, or a facade that maps the calls onto another storage method (e.g. Apple CoreStorage). It may also be worth exploring having a separate mechanism for handling access to arbitrary container-managed attributes (for example, the current user's display name, role, or other profile information) in a similar fashion; currently we use preferences to handle these as well. (NB: web widgets are not explicitly within the scope of the W3C Widgets spec, but I think it would be good to provide solutions which don't rule them out either.) S On 11 Feb 2009, at 02:54, Jonas Sicking wrote: On Wed, Feb 4, 2009 at 1:26 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: This is a pretty radical change; I can certainly see the logic of it in terms of reducing spec overlap. However, it does presume that semantically a widget preference is the same as client-side storage. In our implementation, storage is definitely server-side, so this mechanism would not really work for us. I'm not sure I understand the difference. Can you describe why your implementation wouldn't be able to store the HTML5 API server-side? Are there any changes we could do to the HTML5 API that would allow a server-side back-end? / Jonas smime.p7s Description: S/MIME cryptographic signature
RE: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
Hi Scott, I see what you mean. My mistake: I completelly missed that part of the email. As for your implementation, of course this could be a solution that will accommodate things. Still, there is an important set of functionalities that the HTML5 specs offer that is missed by the Widget.set/getPref APIs: enumeration and clearing. How do you plan to work around this in your implementation? In our case we are thinking to do something similar: keep Html5 storage implementation, making it available, BUT, with some injected Javascript, create also the Widget apis. Our current implementation will work as back end. Regards --- Ivan De Marino Orange Labs Mobile and Web Software Engineer, RD UK tel. +44 20 8849 5806 mob. +44 7515 955 861 mob. +44 7974 156 216 ivan.demar...@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 RD 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: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: 11 February 2009 12:26 To: DE MARINO Ivan RD-ILAB-LON Cc: jo...@sicking.cc; public-webapps@w3.org; UDDIN Rafel RD-ILAB-LON; TIBBETT Richard RD-ILAB-LON Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage Hi Ivan, I wasn't rejecting HTML5 Storage at all, in fact you can see in para 3 I suggested a way of offering the HTML 5 Storage API to widgets in a way that is far less close to final implementation than requiring the use of the localStorage implementation of the HTML 5 Storage Interface. S On 11 Feb 2009, at 10:53, ivan.demar...@orange-ftgroup.com ivan.demar...@orange-ftgroup.com wrote: Hello. This sounds to me a bit too much personal as motivation. The fact that you implement the APIs as server side, because your widget live in a Local Webserver doesn't justify the reject of HTML5 Storage as alternative to set/getPref APIs. By the way, HTML5 Local Storage Key/Value Pairs is all client side: there is nothing that involve any server side. And this should be the same for Get/SetPreferences in Widgets, otherwise the spec will be too close and too focused on the final implementation. Regards --- Ivan De Marino Orange Labs Mobile and Web Software Engineer, RD UK tel. +44 20 8849 5806 mob. +44 7515 955 861 mob. +44 7974 156 216 ivan.demar...@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 RD 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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Scott Wilson Sent: 11 February 2009 09:54 To: Jonas Sicking Cc: public-webapps@w3.org Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage Hi Jonas, We run the widgets from a server, which a web application renders into the browser window using iFrames (a typical web widget architecture). Each widget in its iFrame calls the Widget API getPref/ setPref methods, which are implemented in a locally injected JS library. This library implements the get/setPref methods as AJAX requests back to the server. If the widget used the LocalStorage interface, the server would not be engaged in the storage process, as localStorage is implemented by the browser itself. We might then run into issues where the same widget was instantiated for different users in different contexts - currently we issue an opaque identifier to each running widget instance that enables the server to keep the user preferences separate - though perhaps this could be picked up by the localStorage implementation if it used the querystring as part of calculating the storage scope. We'd still get an issue, however, of users losing all their widget preferences if they accessed them from a different device, or a different browser on the same device, which would be annoying. (Admittedly this is not an issue
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
On Wed, Feb 11, 2009 at 1:54 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Hi Jonas, We run the widgets from a server, which a web application renders into the browser window using iFrames (a typical web widget architecture). Each widget in its iFrame calls the Widget API getPref/setPref methods, which are implemented in a locally injected JS library. This library implements the get/setPref methods as AJAX requests back to the server. If the widget used the LocalStorage interface, the server would not be engaged in the storage process, as localStorage is implemented by the browser itself. We might then run into issues where the same widget was instantiated for different users in different contexts - currently we issue an opaque identifier to each running widget instance that enables the server to keep the user preferences separate - though perhaps this could be picked up by the localStorage implementation if it used the querystring as part of calculating the storage scope. We'd still get an issue, however, of users losing all their widget preferences if they accessed them from a different device, or a different browser on the same device, which would be annoying. (Admittedly this is not an issue for single-user environments...) I have to admit there is a large part of the above that I didn't follow at all. I'll ask you about the specifics if it turns out it matters. I take it you couldn't simply let users use localStorage directly since then if they opened the widget in another browser their stored items would be gone? This is why you want to back up the API with server side storage, right? But even if we introduce a new API called .preferences, won't you have exactly the same problem once the browser that you run in add support for the widget APIs? I.e. once IE or Firefox adds support for running widgets natively, and implement .preferences backed by its own storage you will no longer be able to deploy your own preferences support in those browsers? It sounds to me like the problem isn't with a specific API, but rather that you run inside an environment that you don't have needed control over. What's worse, it's an environment that is likely to collide with all the APIs that you are trying to support. I don't really know what solution to your problem is. However it seems wrong to me to adjust the widget specifications to accommodate your constraints if these adjustments will not help you in the long run anyway. / Jonas
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
On Wed, Feb 4, 2009 at 1:26 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: This is a pretty radical change; I can certainly see the logic of it in terms of reducing spec overlap. However, it does presume that semantically a widget preference is the same as client-side storage. In our implementation, storage is definitely server-side, so this mechanism would not really work for us. I'm not sure I understand the difference. Can you describe why your implementation wouldn't be able to store the HTML5 API server-side? Are there any changes we could do to the HTML5 API that would allow a server-side back-end? / Jonas
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
This is a pretty radical change; I can certainly see the logic of it in terms of reducing spec overlap. However, it does presume that semantically a widget preference is the same as client-side storage. In our implementation, storage is definitely server-side, so this mechanism would not really work for us. It would be pretty trivial for an implementation to map widget API calls onto LocalStorage calls where this is the desired implementation; perhaps it would offer more flexibility to instead define Widget API calls for preferences that follow the same conventions as the HTML 5 storage API, but let implementations decide whether to delegate the implementation of those interfaces to the HTML processor (e.g. WebKit) or instead implement using a dedicated storage mechanism. For example, the Widget object could expose a method for returning a preferences object which implements the HTML 5 Storage interface. In most cases this would simply return the page's localStorage element; however, the Widget object can instead implement this directly with its own Storage if desired. S On 3 Feb 2009, at 11:19, ivan.demar...@orange-ftgroup.com ivan.demar...@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. Please, let me know what you think. Best Regards --- Ivan De Marino Orange Labs Mobile and Web Software Engineer, RD UK tel. +44 20 8849 5806 mob. +44 7515 955 861 mob. +44 7974 156 216 ivan.demar...@orange-ftgroup.com
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
Hi Ivan, All, On Tue, Feb 3, 2009 at 11:19 AM, ivan.demar...@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
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, RD UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@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 RD 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:marcosscace...@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.demar...@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, RD UK tel. +44 20 8849 5806 mob.
+44 7515 955 861 mob. +44 7974 156 216
ivan.demar...@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 RD 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:marcosscace...@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; linuxco...@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.demar...@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
