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 4:23 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On January 4, 2010, Patrick Aljord wrote:
> > > Could be, but the thing would be to use web technologies only.
> > 
> > if i understand it correctly, the request is for easy access to data
> > persistence (separate from configuration data), correct?
> 
> Correct. The reason I'm insisting (and sorry if I sound annoying) it's
> because when it comes to the web plasmoid at least, it makes sense to make
> use of web technologies as much as possible IMO, it's also easier for
> portability (if I want to reuse the widget with apple dashboard widgets or
> windows widgets). Also, html5 storage is not a toy, it's used by google on
> the iphone for example and will get bigger with the time.

relative to what we're doing, it is. i somehow doubt it will work at all with 
remote widgets, for instance. there are lots of technologies out there used by 
all sorts of products, people and projects. use alone does not make it 
suitable, nor does it make it "non-toy". NASA uses relatively ancient CPUs, 
things we'd call "toys" in the modern world, on many/most of their missions. 
the use of those CPUs in multi-billion dollar cutting edge space projects does 
not make them even remotely interesting for Plasma, however.

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.

yes, i think that much of what's going on in web technology today is highly 
short sighted and severely limited. i've seen these cycles before, and what 
we're witnessing imho is "shortest path" development by people who are 
actually interested in something completely different (providing large server 
farm backed services) from what they are producing in this case (client side 
technology to display content and provide interaction). some great stuff is 
happening, certainly, 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. we will be severely 
limited in what we are able to do and severely locked into some very narrow 
ways of working.

the world is slightly more interesting and complex than html5 (or any 
subsequent numbering of that standard will ever likely be) and i refuse to let 
ourselves be limited by it. we can work with it, adopt and adapt, integrate, 
etc, absolutely! but limiting ourselves to its limitations? no.

the reverse is also true, btw. what we do in Plasma isn't meant to be able to 
solve all the problems the html people face, and some of the things we're 
doing are "toy like" in their problem space, i'm sure.

it would be nice if we could all realize that and start using good solutions 
for the problem instead of trying to shape problems around ad-hoc solutions 
created elsewhere. it's a fool's errand.
</rant>

> But yeah, having
> data persistence would be good even if we're not using html5 storage.

let's define an API for this, then. something we can use in any / all 
plasmoids and commit to it actually doing what we need.

as Chani notes, this might be best backed by Akonadi. or it may be better 
being backed by something like couchdb, or even as simple as sqllite. either 
way, that should be an implementation detail. my biggest concerns are:

* a good API (obviusly :)

* maybe async so that we have greatest flexibility and can even get remote 
support for free, e.g. by using Plasma::Service

* easily travel with the containment / applet configuration. i really don't 
want to see a proliferation of files just because applets store data and all 
the trouble (performance, maintenance) that comes with

so we need to solve:

* storage
* API
* mechanism

for "mechanism" i'd prefer a Plasma::Service (i don't think pairing it with a 
DataEngine in this particular case is the best option as they are implicitly 
shared, so we can't keep data published using a DataEngine private); storage 
is a technical detail which requires some research; API is the easy entry 
point and the part that probably most interests you, Patrick...

so let's start there perhaps.

we need to be able to store and fetch little bits of data. is key/value alone 
enough? 

* <boolean> store(key, data)
* <any data> retrieve(key)
* <boolean> remove(key)
* <boolean> exists(key)
* <string list> listAllKeys()
* <boolean> clear()

we could make it so that the service requires an applet associated with it and 
keep its requests to only entries keyed under that applet's id? if we go with 
the Plasma::Service approach, we offer the ability for multiple "documents" 
such as couchdb provides. that would add the following API:

* <string list> listAllDocuments()
* <void> setCurrentDocument()
* <string> currentDocument()

using Plasma::Service, this would give us something like:

Service *s = Plasma::Service::load("storage", this);
s->setDestination(noteId());
KConfigGroup op = s->operationDescription("store");
op.writeEntry("key", "text");
op.writeEntry("value", noteText());
ServiceJob *job = s->startOperationCall(op, this);
job->start();

that's pretty verbose, though it gives us the features wanted. perhaps we 
could wrap that in a convenience API, however, and use a Plasma::Service 
internally (or subclass Plasma::Service?)

something like:

Storage s(this); // where this is a Plasma::Applet or perhaps AppletScript?
s.setCurrentDocument(noteId());
s.store("text", noteText());

in the ECMA script we could even provide access to a global storage object if 
we wished that would then allow things like:

plasmoid.storage.currentDocument = noteId()
plasmoid.storage.store("text", noteText())

or in the webkit version:

window.storage.currentDocument = noteId()
window.storage.store("text", noteText())

it only saves one line of code, though, so i'm not sure it's worth it 
(particularly the "namespace polution") compared to:

var storage = new Storage
storage.document = noteId()
storage.store("text", noteText())

internally such a class would use a Plasma::Service and so would work with 
remote widgets for free

thoughts/ideas/improvements/refinements?

-- 
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