[ghns] khotnewstuff for 4.1

[Frank Karlitschek]

On Friday 25 January 2008, Jeremy wrote:
> On Thursday 24 January 2008 23:55:20 Josef Spillner wrote:
> > 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.

Yes, great idea.

> > > 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.

This reminds me of debian repositories. You have a few default repositories 
and you can add new ones if you know what you are doing. The concept works 
pretty well.

> 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 operatino 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?

Yes. Authentication is very straightforward with REST. REST requests are very 
lightweight and easy to cache on the server side and REST servers and clients 
are easy to implement. This makes it easy for 3rd party developers to provide 
additional services.
Because of this Yahoo, Amazon, Facebook and others prefer REST over SOAP.


> > > 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.
>
> 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.
> >
> > Josef
>
> 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
> results soon.
>
> Jeremy


Cheers
Frank

 
--
Frank Karlitschek
karlitschek at kde.org