references and searches Re: [Kroupware] Kroupware RFC

[Helge Hess]

Bernhard Reiter wrote:
>>If someone else opens the appointment, he can probably jump from the
>>appointment record to the contact participating in the appointment by
>>just clicking on the participant entry in the appointment viewer. Right ?
> Not yet as the handling of calender and contact entries in
> several distinct folders (including shared folders) is not implemented yet.

Ah, OK. Is that part of the Kroupware project ?

>>So the appointment viewer needs to resolve the participant reference to
>>the contact viewer and I would like to understand how this is accomplished.
> The only concept known for this is the email address yet.
> In some sense you can say that part of the design problem 
> has been delayed and won't happen within the Kroupware project.

OK, I see.

> I didn't dig into the problem, but I expect RFC 2445 and the defined UID
> to serve the purpose as referable identifier. 

Yes, but this doesn't solve the problem that it can't be searched 
efficiently on the server and that such a search will potentially result 
   into multiple records (since it's not really a "unique"-id). So the 
UI resolving such a reference is quite complicated (mostly because it's 
need to be handled in any single place resolving the references).

But OK, I see that links are not (yet) considered in the design.

> The idea is that the Kolab server shall not do expensive operations.
> So you are right it is a straightforward design to do the expensive
> operations on the clients.

I think I understood now, but I really wonder whether the gains of the 
design are worth the drawbacks in practice.

>>Seems like
>>writing one is pretty complicated since the Kolab server itself does
>>provide so little functionality in terms of reference resolution and
>>searching :-(.
> 
> It is true that the client has to perfom many complicated operations.
> This is deliberate as it puts power in the users hand and allows
> for a very scalable solution trough a clean design.

Well, so far I cannot see how a scalable web client can be written using 
the architecture, sounds a bit like the information needs to be 
replicated back into a database to host a sufficient number of web users 
on a single server - but that would be against the initial design :-(
But I need to think more about the issue.

> KMail is responsible for caching the imap folder.
> Simple maildir files with KMail indices
> check  ls -al  ~/.kde/share/apps/kmail/imap
> But KOrganizer reads the contents, if you are interested in it,
> you probably have to dig into the code a bit and then ask on the kde-pim list.

OK.

Thanks for your answers,
   Helge
-- 
__________________________________________________________________
Helge Hess                         Email:    helge.hess at skyrix.com
SKYRIX Software AG                 Tel:      +49-391-6623-0
Universitaetsplatz 12              Fax:      +49-391-6623-599
39104 Magdeburg, Germany           Internet: http://www.skyrix.com
__________________________________________________________________
Exchange your Exchange                http://developer.skyrix.com/
__________________________________________________________________