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

List:       kde-pim
Subject:    Re: - Project Status report -
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-07-07 20:57:20
[Download RAW message or body]


On 08-Jul-99 Tim Rohrer wrote:
> Great e-mail.  Having recently joined the list, this really helped me get
> caught up on what is going on.  

Good. I thought it might be a good plan.

> I came over to this list because I want to see a KDE API for LDAP.  Several
> months ago I announced that I was going to work on such an API, but, nothing
> materialized.  I've recommitted to working on it and have been designing a
> KLDAP class.  I'm new to C++ and haven't coded seriously in several years.
> My work might be pretty ugly, but I'm sure people will be willing to help me
> out so that I can contribute to the project.  

When I started coding KDE stuff late last year I hadn't written any serious C++
before. Damn. I let my secret out.

Whatever your code is like, so long as it (half) works it's appreciated. Just
lay it out nicely so I don't get headaches trying to read it ;)

> I know little to nothing about vCard.  I've looked at ldif as it relates to
> LDAP.  I don't think I understand all of your concerns about the data types
> being storeable. As I understand ldif, the data can include whatever you
> want it to as long as you define the objects.  The conversion format I've
> used is ldif2ldap (?) which, if memory serves me, uses the definitions file
> in the /etc/ldap dir to map the data to the new format.  I think the trick
> would then be to define for the applications how they would read the
> definition from the ldif file.  

Ok. So there's a file that specifies the types of the fields ?

Here's a little vCard example:

BEGIN:VCARD
VERSION:2.1
N:Hemsley;Rik;Mark;Mr
FN:Rik Mark Hemsley
NICKNAME:Rikkus
TEL;HOME;VOICE:This is  a phone number
TEL;CELL;VOICE:Mobile no. """ There should be 3 quotes there <-, you know.
EMAIL;INTERNET:(Rikkus' fake address) "Rik Hemsley"@(KDE)kde.org
REV:19990706T224351Z
END:VCARD

I think this should give you some idea how vCard works simply by inspection.
Each of the field names is referred to in the vCard RFC. You are told what
possible value types can be held for a field name.

For example, "FN" -> text-value

So you know how to parse that field. For "FN" you don't bother. For the "BDAY"
field you know that you should expect a date-value.

Where this falls down is when you start adding extension fields:

"X-KDE-SOME-NEW-PARAMETER"

You don't have a clue how you're supposed to parse this, unless you created it
yourself and know about it.

What I need to know is:
How does this work in ldif ?

If you have a line like this:
name: rik

How are you supposed to know what type the value has ?

When I've parsed a vCard, you can do something like:
if (card.has(Birthday))
DateValue bday = card.entity(Birthday)
cout << "Year of birth == " << bday << endl;

If I get this in an ldif file:
bday: 02 September 1998

How do I know that 'bday' refers to a date ?

I think the problem is some huge gap in understanding. I'm used to this :)

Any idea ? Have I got completely the wrong end of the stick ?

> My concern about using vCard is what you said re: Netscape dropping it in
> the next version of Communicator.  Can you add jpegs and other user-defined
> data types with vCard?  That is possible with ldif although I'm  not clear
> about how to do it.

Yes you can add pictures. There are fields specified that explicitly allow
you to give EITHER a picture, encoded as text, OR a reference pointing to where
the picture can be retrieved from (a URL).

> My intention with my network at home is to run an LDAP server so my wife and
> I can share a single address book for all uses.  And, at least for now, my
> wife uses Netscape Communicator and I use kmail.  Hence, another reason for
> me to use LDAP.

Personal interest always helps with enthusiasm ! I didn't expect I'd get hooked
on mail-related development when I started writing a mail client ('I'll just
write a mail client. It'll be finished in a couple of weeks' -> 9 months later
I'm still going).

> I don't want to spout off too much in this e-mail about what I'm planning
> for the KLDAP API but I'm interested in knowing if I should continue the
> project or drop it in favor of the work you are discussing?  And, what
> discussions have traspired re: the data model?  Unless I'm making my
> thoughts about the API too hard, it seems the API must have a standard data
> format, or a way of configuring it for an app, to present to applications.
> I don't think the LDAP API requires this, but it seems it would be required
> so the application programmers know their target.

Please continue ! Having looked through the LDAP RFCs and got scared, I'm keen
for someone else to feel the pain ;)

As regards the API, well we have one available through kab. While it's probably
not perfect and perhaps unsuited to general access to LDAP (which stores a lot
more than addressbooks), it's there as a starting point.

Well as things stand we have a library to parse ldif (and one for vCard) so we
are able to understand two common addressbook formats. There's also a GUI
imminent (re Don). This means that the middle layer and the overall design are
going to come to the fore.

We need to think about design before API, I think.

Off the top of my head (as I type) I'm thinking of some kind of reasonably dumb
kernel that knows how to store and retrieve files to / from a
(directory) hierarchy. This would link to the ldif (or vCard, or both) library
to provide it with the ability to parse and create records. It would provide an
API for storing and retrieving records and doing some GUI stuff. The GUI would
be a separate from the kernel code-wise, but linked in.
The API would become a CORBA interface at some point - worry about that later.

Where would an LDAP API fit in ? Well, it would be nice if OpenLDAP ran as the
'storage' backend and the LDAP API sat between the kernel and OpenLDAP and just
made things easy :)

>> We need more information on ldif to find out how type information may be
>> stored. If it's impossible to store, then we cannot use it as the standard
>> format.
>> 
> I can't claim to actually know about ldif, but if you can provide some
> specific examples regarding the "standard format" that would need to be
> stored in the ldif files, I'll look for ways to accomplish what you want.

Great, thanks. Any extra information helps. I generally achieve enlightenment
by example ;)

> A final question about what we are trying to do here.  Will the backend
> function as a server for all the users on the network? Or, will each user
> set up their own addressbook? Or, both?

Yes, the backend will be set up to be a general addressbook server. It will be
able to do everything via CORBA, so you can just run it on your local machine.
CORBA's network transparent, apparently.

Using CORBA makes the kernel a little smarter than a daemon. If the kernel
isn't in memory when a request is made, it is started. If it's already running,
it's reused. Don't ask me how it works.

'nuff said I think.

Cheers,
Rik


--
KDE - Colour outside the lines  : http://www.kde.org
[[without]] - software for KDE  : http://without.netpedia.net

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