Merging KAuth into KDELibs

Aaron J. Seigo aseigo at kde.org
Mon Sep 7 20:38:43 BST 2009


On September 5, 2009, Oswald Buddenhagen wrote:
> On Sat, Sep 05, 2009 at 02:52:05PM +0200, Dario Freddi wrote:
> > In data sabato 05 settembre 2009 14:36:47, Oswald Buddenhagen ha
> >
> > scritto:
> > > and on a general note, i *urge* you to think through the issues of
> > > integrating with existing related technologies *before* you push
> > > this stuff.
> >
> > Also, what issue did I not think through?
> 
> dunno. you dismissed KAuthorized as "unmaintained" without further
> comment. if that isn't a reason for concern, then i don't know what is.

it's fairly accurate to say that the kiosk framework is quite nearly 
unmaintained. 

right now, kiosk is fairly limited in what it can do, primarily because it 
hasn't been moved forward at all since being introduced several years ago. it 
still works, which is great, and what it does it does pretty well.

it's not easy to do new things with kiosk in spite of its limitations because, 
well, there's little work going into it and new contributions to this area are 
often not met with the most open of arms.

KAuth is a chance to move Kiosk forward by extending its capabilities, and 
Dario and his GSoC student have been trying (and imho succeeding) in following 
the protocols we have in place. it's our job to follow up on that and support 
good efforts when they arrive.

> > If you looked into the code, you would have realized that KAuth lies
> > in a separate namespace, so it's quite unlikely to have stuff
> > conflicting with KAuthorized, which has a completely different scope
> > and functionality.
> 
> have you considered that this is exactly the problem? i can see only two
> options: either you have two totally orthogonal classes/namespaces with
> very similar names (which is just plain bad api), or thought should be
> put into integrating the two (i know that the underlying technologies
> are different, but if it's still just the same thing at two different
> layers, then a common api abstraction might make sense).

unfortunately, again likely due to the lack of people around who understand 
and know the kiosk framework, Dario didn't know a whole lot about KAuthorized 
and the other bits at the time. so we sat down last week while at Tokamak 3 
and i walked him through the various pieces of Kiosk.

it's pretty evident from looking at Kiosk (inc KAuthorized) and KAuth that the 
two are complimentary and that there are areas they can work together. there 
are other areas that are orthogonal (such as [$i] in config files and 
cascading config dirs; that's not useful or relevant to the areas KAuth works 
on)

we also discussed, quite specifically, how to make KAuthorized and KAuth work 
together. KAuthorized is a nice, simple interface for an app to ask "should 
this app show and allow this kind of action?" and KAuth is a nice interface to 
getting that information from the system. KAuth can do a lot more than what 
KAuthorized provides, but KAuthorized is a nice convenience API for asking the 
kinds of questions it's there for.

so it seems, looking at all the code there, that the two don't conflict at all 
but can and should work together. Dario even drafted a concrete method to 
allow KAuth to feed KAuthorized information behind the scenes when 
appropriate.

so the concern over "how does this work in the bigger picture" is absolutely 
valid. those concerns have been cataloged and work is being done on them.

if you'd like to help out, that'd be great. kiosk needs more hands writing 
code and KAuth is quite pleasurable to work with. there are other areas that 
kiosk needs work as well, of course.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090907/04fde9c4/attachment.sig>


More information about the kde-core-devel mailing list