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

List:       kde-pim
Subject:    Re: Addressbook
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       1999-07-04 13:33:31
[Download RAW message or body]

On Fri, 02 Jul 1999, Rik Hemsley wrote:
> I'll make a pim module and put my vCard parser and your dialog work in
> there.
Excellent.
 
> >> Well, vCard entities have an optional group name. That means the whole card
> >> can
> >> be within one group. I'm not quite sure how it's supposed to work for the
> >> rest
> >> of the card. I'm storing the groups anyway.
> > Hmm, only one group? (Not to sure what you mean by "the rest of the card"
> > btw).
> 
> Each 'Content-line' can have a group.
> This means you could have something like this:
> group1.BEGIN:VCARD
> group2.FN:Rik Hemsley
> group3.VERSION:3.0
> 
> I'm not quite sure what this achieves.
> [lots of stuff about vCard and groups]
I've been thinking about the grouping problem. I can see two uses for groups
1) To create an e-mail alias for a list of e-mail addresses.
2) To make the list of addresses more manageable by partitioning the list into a
hierarchy (similar to bookmarks in web browsers).

I think these are different problems and require different solutions.
1) Can be solved by allowing different types of entries in the "addressbook",
say vCard, vCalendar, todo list item, journal entry item, e-mail group, e-mail.
That means that it is no longer an address book but a database (or perhaps
infobase would be a better term).

In a sense I guess a pim can be though of as just an application that just
supports different views of a database. I suspect MS outlook is implemented
like this.

2) I guess a hierarchy is best handled by having a separate file (ie table) for
each folder.

Note: I don't want to use kab to store e-mail messages but I would like to
have a view that enables me to search my entire 'infobase' and see a list 
containing headers for all types of information stored in all known infobases. I
would like to see e-mail clients provide a kab like interface for searching
email messages. (Though someone did recently state that kmail doesn't even allow
searching in the message body at the moment so that takes higher priority). I
think you've already raised this issue in your mail os documentation, so I'm
just stating how it is related to the grouping problem.

I guess what is need is a directory service for kab type infobases. This raises
these issues:
1) I wonder how similar this is to the problems  LDAP addresses. Actually it
would be pretty cool if the pim could provide views of infobases (not really
sure if that's the right word) accessed via a LDAP server. LDAP looks
interesting. (Note I'm just saying this would be cool and we shouldn't do
anything to make this very difficult in the future but I have no intention of
doing the work to make this a reality at the moment)

2) Similarly it would be cool if the pim was flexible enough to allow views of
KATABASE data. It seems that there is opportunity for us to collaborate with
the katabase folks, but there is also the danger of duplication of effort. I
hope that someone from katabase is aware of what we are doing here.

> >> A vCard can have an unique identifier. If it doesn't have one, we can create
> >> one.
> > I think every vCard should be given one.
> 
> Ok, that's easy and was what I was intending doing.
> 
> >> I'll probably implement operators '<<' and '>>' for the vCard components so
> >> we
> >> can stream them. I use this for rmm (the Empath mail parser) and it works
> >> well,
> >> except for the nasty problem of no error checking unless you use exceptions,
> >> and
> >> that Qt's stream operators don't throw exceptions.
> > Yeah bummer about the whole exception situation. I guess C++ code is
> > bloated due to using exceptions or ugly due to handling errors without them
> > or
> > error prone due to not handling erros at all :-(. 
> > 
> > Hopefully compiler technology improves and the cost of using them becomes
> > more acceptable.
> 
> I'm not quite sure how to progress here.
> >From the rfc:
>    CHAR         = %x01-7F
>         ; Any C0 Controls and Basic Latin, excluding NULL from
>         ; Code Charts, pages 7-6 through 7-9 in [UNICODE]
> 
> I presume this means single-byte unicode, though I don't know enough about
> Unicode to be sure. If it is, then we can just save to a text file as 8-bit.
> 
> > I guess I'm working on "complete" now, though most users will only use the
> > first
> > tab of the addressbook entry editor dialog, which is pretty "simple". 
> 
> That's fine. So long aren't presented with the option to fill in their
> geographical location via link-up to a GPS on the first screen ;)
I have to still add a GPS field though it can easily be added as an entry in
the speadsheet like tab.

> This is how the rfc specifies tel-type:
> 
> tel-type     = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG"
>                 / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN"
>                 / "VIDEO" / "PCS" / iana-token / x-name
> 
> So you can have something like this:
> TEL;TYPE=work,voice,msg,pref:3972109471;TYPE=home,isdn:39249444;TYPE=X-AnotherTy
> pe,modem:30482882
> 
> This just means that vCard does it in a different way to Outlook.
Internally I'm using a QDict of (type/value) pairs I think this makes sense.
We'll talk about this again after I e-mail you my code, yes?

> 
> > Okay, here are the outlook fields. I was planning on storing all of these
> > fields as strings. I'm wondering whether vCard expects certain fields like
> > BDAY
> > to be stored in a certain format.
> 
> Yes, many of the vCard values have their own formats. Some of them are defined
> in rfc2425 ('A MIME Content-Type for Directory Information'). Others are
> defined within 2426 (the vCard rfc), such as utc-offset-value:
> 
>    utc-offset-value = ("+" / "-") time-hour ":" time-minute
>    time-hour    = 2DIGIT                ;00-23
>    time-minute  = 2DIGIT                ;00-59
> 
> Storing fields as strings just loses us the ability to have them automagically
> parsed into usable objects and therefore searched/sorted 'correctly'.
Unless the string is a canoncial representation of the value, I mean I'll try
parse text entered and reformat it into the correct form. Hmm, I would like to
accept garbage values but somehow signify the fact that they weren't stored in
preferred format.
 
> The vCard parser's job is to create real live objects for types it knows about.
> This will mean you can do this:
> 
> using VCard; // Doesn't work in my egcs, but I just use VCARD:: instead.
> 
> VCard v("BEGIN:VCARD\nBDAY:1996-04-15\nEND:VCARD");
> 
> if (v.has(EntityBirthday)) {
>   DateValue * d(v.contentLine(EntityBirthday).value());
>   cout << "Date is " << d->day() << "/" << d->month() << d->year() << endl;
> }
> 
Okay, I see. I take it that DateValue is just psuedo code right? Is there such
a type? (I know of QDate)

> > Account
> > Anniversary   None
> > Assistant's Name           
> > Assistant's Phone
> 
> I think we can just put what we feel is useful in and allow for extensions via
> the spreadsheet-style widget.
> 
> Perhaps this is a job for the group thing ?
> 
> assistant.TEL:02838 32844
> 
> That might just be it.
Hmm, not sure. As long as the saved file is a valid vCard it should be okay.

> I'd really like to see an adaptable GUI, but I don't think anyone wants to do
> that. Perhaps when I've finished my current 3 projects ;)
> [cut]
Okay, I see where you are going. The first tab in the address entry editor
would require a pretty sophisticated KConfig file. You'll should see that when I
send it. 

I have no problem with supporting this type of thing as long as a sufficiently
expressive grammar for the KConfig file and sufficiently powerful parser are
created. Personally I would rather finish off the current entry editor dialog
and move on to the addressbook browser window.

... 
> I think you should see that with this kind of system we get to choose exactly
> what goes on the dialogs and where.
Yes I agree, it is a matter of priorities.
 
> The code for getting entity types etc is already in my vCard parser.
> 
> >> We can just have a simple lineedit for the post code and call it something
> >> different according to locale. Validation would be pointless.
> > There is a nice little dialog for entering addresses in outlook, it
> > pops up when leaving the address multiline edit control under certain
> > circumstances that I have yet to determine (the address validation I was
> > thinking of) or when they click on a button. I might keep things simple to
> > start
> > with and only show it if the user explicitly clicks on the push button that
> > launches it.
> 
> Ok. That's got to be better. I can't imagine a bigger headache than trying to
> validate addresses written in Cantonese.
Hehe, the Outlook algorithm might just be checking to see if the right number of
lines have been entered. I'll begin with the non-fascist style.

> >> You could possibly use something from kcmlocale for the country combo.
> > Hmm, I only know of one that lists languages not countries.
> 
> I was just thinking of changing 'English - UK (en_UK)' to 'United Kingdom' etc
> as a basis, seeing as there's lots of flags and a ready made widget :)
I have a list of countries I'll store them in a combo box.

BFN,
Don.

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