[Kroupware] Kroupware RFC

[Bernhard Reiter]

On Monday 07 April 2003 01:13, Helge Hess wrote:
> Martin Konold wrote:

> Two more general questions for understanding the design:

I'll try to answer as much as I can.
Probably Martin ir Bo will fill in missing points.

> a) How do you deal with references ?
>
> If entries are potentially copied there can't be any links between the
> entries (eg between an appointment and a contact of a contact folder
> invited to the appointment) ?

Unless something we invent a way to reference this.

> Obviously the IMAP4 uid isn't suitable for that because of the copying
> semantics. Do you use some special mail header field (msg-id ?) or
> internal key for locating an entry ? 

No. But I don't fully get the question.
The E-Mail address is the reference link for most tasks.
Then each single entry has an imap number.

> Is there a specific (and efficient)
> IMAP query to locate such an entry ?

Cyrus imapd has an efficient way to find the file in question.

> How does the current interface (eg the appointment editor) deal with the
> case that a record was duplicated on conflict ? 

If the appointment is fresh, than two concurrent ones will be creates
because it is possible to have two appointments at the same time.

If the appointment is the same
we plan to have a resolving dialog.

>Does any single GUI
> component resolving a reference need to deal with the fact that the
> query may return multiple objects and provide proper resolution GUI ?

No as one event as one imap number.

> b) What is the general strategy of dealing with queries ?
>
> Given that Cyrus doesn't know about the attributes contained in an
> iCalendar message it can't run a query like "give me all appointments of
> this folder in the week xy in year 20xz". Obviously it wouldn't be
> acceptable for the client to go (online) over each of the thousands of
> appointments contained in a folder, query the content and perform the
> query itself.
>
> So do you rely on the client keeping a local, domain specific and
> indexed cache of the information (much like local searches in Mozilla)
> and let the client perform the query operation ?

The KDE Kolab client should have a full cache of the interesting
calender entries. Thus it is performing searches locally.

> If this is the case, I'm interested in your approach for dealing with
> that in the webclient. Were is the webclient going to store it's local
> cache ?

The concept for a webclient is not finished yet.

> What is the maximum number of appointments and contacts per folder the
> current Kolab Client can handle locally on usual hardware ? 

We did not go to the limit with our tests yet.
Bo probably knows more about where we stand.
As far as I know a couple of thousends are no problem.

> Does it use
> a Berkley DB for storing the attributes of an appointment ?

I believe KOrganizer does not, but I'm not deeply into the KOrganizer
implementation details.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2231 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kroupware/attachments/20030410/eae24af6/smime.bin