On January 4, 2010, Patrick Aljord wrote:
> On Mon, Jan 4, 2010 at 4:23 PM, Aaron J. Seigo <ase...@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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
