[ghns] khotnewstuff for 4.1

[Josef Spillner]

Hello.

Am Freitag 25 Januar 2008 01:58:49 schrieb Jeremy:
> 1. Users need a way to add additional providers for a given type of data.

Isn't this a recursive problem? "Get Hot New Providers" :-)

> For example, if someone wanted to they could add gnome-look.org or
> something as a provider of wallpapers.  Or a school could set up a ghns
> server or a website that provides xml and vocabulary files for parley each
> week for it's students.

Yes, those are valid use cases.

> Currently all providers are loaded from a central 
> place (or places) which have lists of providers.  Users could concievably
> add more providers from a dialog that comes up from a button in the
> download dialog, or from a kcm, or something.  The simpler the better
> probably.

We could make the ProvidersUrl a string list (ProvidersUrl*s* for backward 
compatibility with the old entry) and then load all of them. In the usual 
case, there would be one on the internet and one on the hard disk or local 
network.
However, the GUI should also make it clear that adding providers at will might 
be a security risk.

> 2. Users need a way to provide username and password for a given domain. 
> That way schools server could be set up to only allow download from
> registered students, upload from registered teachers, etc..  Also will be
> needed for kde-look.org and the other sites to do upload with
> authentication.

With REST this is easy to do per operation or per resource.

With SOAP-like interfaces, the current DXS allows putting a .htaccess file 
into the CGI directory, but this is an all-or-nothing approach with a 
granularity only on the file (CGI script) level. Everything else more 
fine-grained will need WS-Security which nobody would ever want to implement. 
In such scenarios, REST is really the way to go.

> 3. We need to have an install to system folder ability, so IT departments,
> or teachers could download data for marble, or kgeography have it install
> to the system folder, and then be accessible to any student that logs into
> the machine.

This is obviously one of the longest wishlist items around. My idea of how to 
implement it: In the KCM, configure which users have the "global 
installation" role. By default, this would be root, although we shouldn't 
encouraging working as root. Linux distributors etc. could make this the 
first/default user. Every user with the "global distribution" role will have 
a button or installation option in the download dialogue to install the files 
system-wide, i.e. $KDEDIR(s) instead of $KDEHOME. The KCM should also make it 
easy to specify an arbitrary directory (e.g. /nfs/kdeaddons) to be added to 
$KDEDIRS so that apps which use KStandardDirs will find the data 
automatically.

Another item: Currently I have one student working on a KDE/fd.o kind of 
topic, which is a bridge between D-Bus and Web Services. The progress is 
about 50%. Once this is done, I can finally continue the KNS daemon to speed 
up the dialogue invocations.
In addition, I'm also looking for more challenging topics which could be of 
use for desktop-related service engineering. (Which could be discussed on 
kde-services-devel.) Anything which requires more than just coding already 
qualifies for the first round :-)
My next bunch of students will start around March.

Josef