Poll: what do you think is the future of widget data storage APIs ?
"Stéphane S."
I write this message because I am a bit confused actually by the many
directions that widget data storage APIs may take in the short term.
Just to remember, currently in mywiwall, as in many widget APIs, we
are using a basic key / value pairs storage with a
widget.setPreferenceForKey (<datatype> preference, <string> key)
widget.preferenceForKey(<string> key)
Recently there was a move at the W3C Web Apps WG to change the Widget
APIs and Events so that preference storage uses the "Web Storage" API
from HTML 5:
See http://dev.w3.org/2006/waf/widgets-api/#the-preferences-attribute :
<<<The preferences attribute provides a Storage object for a widget.
The Storage interface is defined in the [WebStorage] specification.>>>
And for Web Storage : http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0301.html
This has raised many discussion such as : http://dev.w3.org/html5/webstorage/
In particular an issue raised by Scott is that the preferences could
be replicated between several instances of the same widget in a
context (as he does with Wookie), and hence the specification should
not force the storage object to be local.
Now there seem to be another contender which is also quite interesting
if we consider the scenario of widget instances shared in a context:
the Google Wave API for widgets which introduces a Shared State API:
wave.getState() : For example, wave.getState().get('count') returns
the value for the count key.
See http://code.google.com/apis/wave/extensions/gadgets/guide.html
In fact if you do merge the widget and the wave objects (as Scott as
suggested in a previous post : http://groups.google.fr/group/talk-about-widgets/browse_thread/thread/3cc2cacd80f3c077)
then you can wonder why not storing widget preferences as a shared
state in a Wave !
What strikes me also is that the "Web Storage" specification announces
a "Structured storage" API (currently based on mySQL but this is also
heavily discussed at the Web Apps WG: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0106.html)
, which reminds me of some experiments we are doing with a special
version of mywiwall about adding XML database capabilities to widgets...
So here is my question: how do you think widget data storage APIs
should evolve in the future ?
For instance:
- shouldn't we disconnect the concept of preferences, from the concept
of a shared state and create two different sets of APIs ?
- shouldn't we introduce more explicit database storage capabilities
in widgets so that it becomes easy to develop useful client-side only
widgets (I mean widgets that just combine existing Web services with
a capability to create documents stored in a shared (or not) database) ?
What do you think ? What else ?
Stéphane
---
Scott Wilson
We store Preferences and SharedState separately as they operate in
different scopes; they are also implemented on the server side as
different tables with different structures (SharedState items are not
keyed by widget instance, for example, but only by context).
Shared State has a much higher overhead than Preferences, as it uses
Comet, and so its useful to keep them as separate features; we only
initiate comet if the Widget config requires Wave (or our previous
shared state API).
So overall I think its a good thing to keep Prefs and State separate.
It would be nice if they both used the same API for accessing data,
and in fact I raised a Bug over at Google Wave to make their State
object also implement HTML5 Storage. They closed the bug basically
with no interest in complying with the standard :-(
For client-side only widgets, the obvious thing to do is:
Widget.preferences = function(){return localStorage;};
Structured Storage has seen a lot of changes in W3C, between SQLLite
and XML and all kinds of other things. I don't think its really
settled yet what to do. For now, sticking JSON into tuple storage
looks to be the easiest!
S
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Talk about Widgets" group.
> To post to this group, send email to talk-abou...@googlegroups.com
> To unsubscribe from this group, send email to talk-about-widg...@googlegroups.com
> For more options, visit this group at http://groups.google.fr/group/talk-about-widgets?hl=en
> -~----------~----~----~----~------~----~------~--~---
>