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

List:       kde-pim
Subject:    Re: [Kde-pim] akonadi: client-server?
From:       Jan Callewaert <jan.callewaert () gmail ! com>
Date:       2006-06-17 13:30:20
Message-ID: 200606171530.23384.jan.callewaert () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]


Op vrijdag 16 juni 2006 18:55, schreef Till Adam:
<snip>
> We've talked before about one-url setup schemes, and I agree with your
> that it would be nice to have.
>
> > Are there any provisions done for this, or will it be that the
> > configuration has to be set up on each computer again?
>
> So far no one has tackled it, but I think there isn't anything in the
> design that would prevent it.
>

I have been thinking some more about it, also with the objectives of akonadi 
in mind, especially easiness to add a new component.

I have attached a sequence diagram illustrating the process of a user starting 
an akonadi client.

1: It should be possible to have one config for different clients, having 
different supported components, further called capabilities inspired by the 
naming of IMAP. So upon startup, the user process asks which capabilities are 
supported at the configuration interface. The interface can be local or on a 
server (a server first requires authentication of course).

2: The user process checks which capabilities the client supports. If a 
company has added a custom component, but this component is not available in 
a standard Kontact, you still want to be able to use the rest of the 
capabilities the client supports.

3: For every common capability, the configuration is asked at the 
configuration interface. The user process passes it on to the client which 
loads the appropriate components with the configuration object (4).

The configuration interface could use the standard kde configuration 
components, which would support multiple backends in KDE4 (e.g. an external 
akonadi server could be used).

In the config object, it would be stated where to find the information to load 
the components. E.g. an IMAP server could be listed from where to download 
the mail, or it could specify to ask the information to an akonadi server 
(not necessarily the same as where the configuration is stored) with the 
WebDAV protocol.

<snip>
> Patches should go to this list, I guess, and as for coordination, I'd
> invite you to come by in #kontact, so we can maybe get that wiki page
> (with a more detailed todo list) started and filled with content
> together. Hopefully that might attract people to join us.
>

Ok, great. I hope I'm not exagerating with my ideas. It's just something I've 
been thinking about already for quite some time. Right now, I don't have time 
to hang around a lot on IRC (my hopefully last exam of my study career is 
next week) but next week, I'll try to hang around. But before sending 
patches, there pbb should be some plan what to do I guess.

Please send your comments at my idea, I'm sure you guys have a lot of 
experience in this stuff, and more people can come up with something much 
better I'm sure. If this interests you, I can add more details, but this is 
just an early idea.

Regards,

Jan

["initialisation.png" (image/png)]
[Attachment #8 (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]