dah-dah-da-daaaaah! synchrotron!

[Frank Karlitschek]

On 05.01.2011, at 23:33, Aaron J. Seigo wrote:

> On Wednesday, January 5, 2011, Marco Martin wrote:
>> On Wednesday 05 January 2011, Aaron J. Seigo wrote:
> 
>> if it ends up to be pulled from all KDE users, couldn't it become a bit of
>> a burden for KDE servers?
> 
> yes. on the other hand servers are pretty powerful these days and this service 
> is rediculously lighweight.

Exactly. And OCS is using REST for the communication. REST is stateless and atomic and is super easy to cache and lightweight for the webserver. It also work with server clusters via round robin for example. If the backend like for example a database or git is also fast the system is as fast as it can get.

I don´t have a problem with the updater on openDesktop.org and I don´t think the KDE servers will have a problem.




> limiting pulls for updates to either on-demand or weekly (with a randomly 
> chosen day and time on each system) should be doable, i'd think. esp if we 
> extended synchrotron a bit to accept a set of items to request update status 
> for, which would make it a single roundtrip and hit to the database.
> 
>>> i'd like to make this easy for DataEngine and Plasmoid developers to take
>>> advantage of, preferably by putting such logic right into DataEngine and
>>> Applet itself. it would be nice to see the logic for this in libattica so
>>> that it can be shared by all kinds of application (imagine starting
>>> Palapeli and having a dozen or two puzzles available, new ones appearing
>>> all the time, via synchrotron in the start up listing!).
>> 
>> it makes sense: with attica seems quite easy to do anyways, from a quck
>> source read AtticaProvider from knewstuffs3 has functions to do that (that
>> atm is just used to display the update button)
> 
> yes, much of it is already there. i would like to avoid having to hit the 
> server once for every item, though. batching up update checks would be 
> awesome. this is not what OCS was designed for, though; OCS is pretty much 
> opendesktop.org's-webapi-beomes-a-spec from what i can tell, and so things 
> like efficient mass update checks never came into play.

Well the current OCS version (1.6) has a lot of input from Intel and Nokia (Maemo, MeeGo), Midgard, OpenOffice.org and others.
So it´s way more than just openDesktop.org already. :-)

I´m not sure a batch update call is really needed because this call would have a very low cache hit rate on the server compared with atomic checks for single plasmoids.

But a batch check call could be added to the next version of the spec of course if it makes sense.


>> i don't think atticaprovider is exported, but is easy to do and the needed
>> stuff could be pushed down.
> 
> agreed.. probably something we should discuss with the attica team.
> 
>>> in the immediate future, while we work on these kinds of improvements,
>>> we
>>> 
>>> can use the normal GHNS dialogs from knewstuff3 to test things out.
>>> 
>>> (on a side note / as a bit of useless trivia: synchrotron came out of
>>> design work i did over the holidays for plasma classroom :)
>> 
>> tell us moar :D
> 
> not yet :P 
> 
> all i'll say for now is that synchrotron was page 1 in the (paper) notebook 
> and now it is "done"; plasma classroom thoughts took up the next few pages. i 
> need to revisit them now and figure how to tackle these things and how to make 
> sense out of what i wrote down christmas :)
> 
> -- 
> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel


--
Frank Karlitschek
karlitschek at kde.org