[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Systemusers as Addressbook resource
From:       Tobias Koenig <tokoe () kde ! org>
Date:       2005-07-11 11:59:56
Message-ID: 20050711120058.GE2401 () ghostdog ! localnet
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sun, Jul 10, 2005 at 04:38:12PM +0200, Friedrich W. H. Kossebau wrote:
> Hello,
Hi Friedrich,

> How could this be achieved? For one I wonder why noone seems to have ever 
> thought of using one of the first of all addressbooks in the unix world, the 
> entries in passwd (and .plan & .project)?
There was such an resource somewhere in CVS already, but I can't remeber
where, so I guess it's also outdated ;)

> Is it because NSS LDAP is the answer for any bigger installation and connected
> to directly (help, I do not know much about NSS or LDAP)?
When you use getpwent(3) it doesn't matter which backend is used by NSS,
you can access the system user list in a unique way.

> There is a class called KUser[0] which is based on the information hold in 
> passwd. But the information there is not guaranteed to help with a contact: 
> There might not be a valid email address build by the login name and the host 
> name, the phone entry might not be supported.
When the system doesn't provide an entry for phone number in
/etc/passwd, then the user has no phone number. When an entry exists,
it's read by KUser, so what's the problem?

> Then passwd is only one approach to 
> information about a user. Many bigger installation are IIUC based on NSS LDAP 
> where perhaps more information is given, like presence id, messaging address 
> etc.
That should be mapped to getpwent(3) by the NSS LDAP plugin, so I see no
problem here.

> So it would be nice to have some backend which uses whatever information 
> source is available to deliver contact/presence* information about a system 
> user.
That's what NSS is for ;)

> I thought about enhancing the KABC::StdAddressBook and give it some System 
> users resource.
Adding a resource by default, which uses KUser as input should be
enough.

> But does the KAddressbook system support mapping? What if one 
> has some other user already in his private addressbook? How could additional 
> contact information not delivered by the system be stored?
This issue will be solved in KDE 4.0, for KDE 3.5 we should use a
read-only resource.

> And what would the API to request the address information of a local system user look like 
> (remote system user mapping would be nice to have one day, too)?
You could assign all contacts loaded by this system resource a special
category (e.g. 'System User') and filter for this category where ever
needed.

> While we are on it, how to integrate the system user face (the one used by kdm and 
> hopefully soon across KDE)?
Either KUser will know about them or the resource looks for them at the
appropriated places.

> * finger is dead?
From the security point of view, yes :)

Ciao,
Tobias
-- 
Separate politics from religion and economy!
The Councile of the European Union is an undemocratic and illegal institution!

["signature.asc" (application/pgp-signature)]
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de


_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

[prev in list] [next in list] [prev in thread] [next in thread]