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

List:       kde-pim
Subject:    Re: [Kde-pim] Systemusers as Addressbook resource
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () kossebau ! de>
Date:       2005-07-11 13:20:39
Message-ID: 200507111520.55076.Friedrich.W.H () kossebau ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Am Montag, 11. Juli 2005 14:00, schrieb Tobias Koenig:
> 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 ;)

Thanks for the pointer, will search for it.

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

Yes, but this limits one to the passwd semantics.

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

The problem with the phone number is that the additional GECOS informations 
might not be really in use and thus not provided. And this is just a minor 
problem. Please note the others.

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

As the entries of pw_gecos are somehow standardized (and size seems limited) I 
wonder how one could place im address, mobile phone number etc. in the passwd 
entry without breaking to much ;)

> > 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 ;)

But being limited to passwd semantics?

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

Or operates directly on getpwent and ldap and whatever add. informations are 
there. Rather would I like KUser to use the addressbook resource (or 
optionally even StdAddressbook).

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

Read-only resource means? Does this relate to mapping or to storing own 
information to a system user?

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

Resources can still be used directly, yes? Or do they always have to be 
accessed via some framework?

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

Well, I think it makes more sense to create a system user resource wrapping 
all the backends and having KUser extract its information from there.

Also KUserGroup might draw its information from there.

I browsed kdepim a little without success, so could you please point me for a 
simple local Addressbook KResource, like the file one?

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

Perhaps time for sfinger? ;)

Regards
Friedrich

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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/

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