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