Client-side architecture for a widget portal ?
Stephane
This is just to suggest a silly idea, and to get your feedback to know
if it is worth to investigate.
The starting point is the fact that WebStorage API [1] are on their
way to be implemented in major browsers (including some database API
that go beyond key/value pairs as per Safari), so I am wondewring
wether it would be interesting to develop a "local" widget portal that
the user could simply execute on his/her computer by opening a "my-
portal.html" Web file. Of course, the widgets would be displayed
locally in the user's browser.
In this scenario, I guess that the widgets packages could be either
uploaded to the local file system too (such as Desktop widgets), or
they could also be linked and downloaded at portal's opening. But the
first option would speed up startup.
If such approach would be feasible, it could also evolve towards
"collaborative/social" widgets (that share their preferences/states)
by connecting to a remote Storage/Configuration Web server that could
be limited to synchronizing different widgets in different local
portals.
I am not sure of the avantages of this approach, but I can cite:
- better startup time (if widgets are stored locally and save their
data locally)
- by moving the management of basic widget/portal preferences (layout,
sizes, colors, etc.) to a local engine, a potential remote server
would be more focus on collaborative features (state sharing,
management of groups, etc.) : better separation of functionalities
- easy installation (just copy a package to local drive and open an
html file)
- no need for authentification (considering the user is already logged
to his/her own PC)
I do not really see inconvenients,
What do you think of it ?
Stéphane S.
---
[1] http://dev.w3.org/html5/webstorage/
PS: State of Browser’s Implementation of WebStorage analyzed in http://trivero.secdiscover.com/html5whitepaper.pdf
As previously stated, many browsers has already started to implement
many new features of HTML 5:
• Gecko, used by Firefox and many more, allows session storage and
global storage since version 1.8.1 (Firefox 2.0,
October 2006);
• WebKit, used by Safari and recently implemented in Qt 4.4, allows
database storage since version r27xxx (introduced
subsequently in Safari 3.1, March 2008), and since development version
r34xxx (and probably since future 4.0 version of
Safari) allows also local storage and session storage;
• Trident, used by Internet Explorer, allows session storage and local
storage since version VI (IE 8 beta 2, August 2008);
Presto, used by Opera 9.60, doesn’t supports anything of the HTML 5
client-side storage.
alain....@tudor.lu
Dear Stéphane,
we already thought about this option which seems interesting.
There are now some abstractions libraries that permit to port the webstorage api on top of unsupported browsers (by using for example flash local shared objects iirc)
One the use case side, we envisaged to build with this kind of local portal a firefox extension enabling a personalized startup page.
There are already such extensions but they are not compatible with w3c widgets. It could be possible to use Mozilla Weave to synchronize widgets and their data with a remote server...
A.
Stephane
try it yet, but you can check:
Widgeon
A W3C Widgets implementation using XULRunner
http://code.google.com/p/widgeon/
Looks like a client side implementation of a widget engine / widget
container in XUL + Javascript.
Stéphane
---