how can I access DataEngines from JavaScript in the Web Plasmoids?

[Aaron J. Seigo]

On January 4, 2010, Patrick Aljord wrote:
> On Mon, Jan 4, 2010 at 6:10 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > relative to what we're doing, it is. i somehow doubt it will work at all
> > with remote widgets, for instance.
> 
> Ok I didn't think about remote widgets. Point taken.
> 
> > in particular, it's pretty evident that html5 storage has been designed
> > for use in web browsers. it's really that specific. because we don't use
> > html anywhere else, right? *sigh* the people looking after the web
> > standards are truly myopic.
> 
> I just assumed that the web plasmoid was done to write browser or web
> apps in plasmoids.

it's more the other way around: the idea is to write plasmoids using web 
technology. yes, you can certainly shove a regular web app into a plasmoid 
using this script engine, but that's not the main reason behind it.

a webkit plasmoid should still exhibit the behaviour of a plasmoid (e.g. it 
should be remotable, themable, etc). it should still have access to things 
that we can provide in a nicer / more powerful way and allow for the creation 
of items that can be stacked together to create larger applications (the whole 
"widget" idea in Plasma).

a lot of people know/understand html/js and there are a lot of resources that 
are easy to get to using html/js; the webkit script engine provides a bridge 
between Plasma and those advantages. it doesn't, however, turn Plasma into a 
bunch of small web browser frames. we already have a widget for that :)

the browser-centric features in the html standard are therefore of less 
interest than the general render/fetch/run javascript features.

> > but if the world goes "all in" on the web technology
> > boat 100% we will be in a world of pain as time goes on.
> 
> I don't think so, stuff like canvas, web sockets, fast js engines,
> webgl or even native client will turn the browser into a powerful
> platform not only for traditional web apps but I guess time will tell.

"web services" are certainly a "permanent" part of computing; the browser and 
html-for-the-browser i doubt (at least as an app dev platform). it's been 
tried numerous times and tends to fail for the same reasons, despite all the 
apparent upside to such things.

in the end all they are doing is, at best, reinventing what we already had on 
client side computing 10+ years ago only with far more overhead. the saving 
grace? it comes with networking and advanced text and image rendering built in 
and a well thought out deployment strategy.

given the amount of resources being thrust into it, it's a really stupid 
approach to the problems of network access, rendering and deployment. only 
deployment is even remotely difficult, and even that has reasonable solutions. 
solving a "5% of the cost" problem by spending the other 95% all over again 
(and so far poorly) is insane.

web apps will certainly get more advanced. the resources pouring into that 
will ensure it happens. but those working on such things really ought to lift 
their heads up to get some perspective on what people use, want and need 
combined with what else is out there that makes sense in a complimentary 
fashion. some research about how new technology tends to displace rather than 
replace might even be useful.

instead, we'll spend another N years making slower progress in the tech 
industry than we really ought to due to the spending decisions of certain 
large companies. which is to say, business as usual. ;)

> > thoughts/ideas/improvements/refinements?
> 
> I like your version with no namespace pollution better:

:)

> > var storage = new Storage
> > storage.document = noteId()
> > storage.store("text", noteText())
> 
> Interestingly, the couchdb guys wrote an API on top of html5 storage
> to turn it into a key value store, it looks like this in JS:

yes, the storage side could be almost anything really. we'll have to explore 
more as to what would work out best. for Plasma, it should be something that 
doesn't require an html5 runtime, however, for the other languages and 
bindings out there.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks