[ghns] khotnewstuff for 4.1
jeremy at scitools.com
Fri Jan 25 07:53:23 PST 2008
On Thursday 24 January 2008 23:55:20 Josef Spillner wrote:
> 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
> However, the GUI should also make it clear that adding providers at will
> might be a security risk.
Yes, this wouldn't be too hard.
> > 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.
Yes, I saw REST a bit at the release event (thanks Frank) it looks nice. I'm
not really worried about the server side of things, just wondering how/where
to add the ui for this. Do we want/need a KHotNewStuff kcm? or should we
just add a menu to the dialogs or something?
> > 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
Yes, or it could be like other apps that use ksudo or whatever to get admin
rights (I thought systemsettings had something like this at one point...)
Anyway, should be doable. Again the question is make a kns kcm, or just
another button/menu on the dialogs?
> 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.
KNS Daemon? that sounds interesting. I'm working on making the dialog work
asynchronously better with model/view and goya to draw the buttons, etc.
Depending how soon goya moves into kdelibs, you should be able to see the
More information about the ghns