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

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi Brainstorming
From:       Tobias Koenig <tokoe () kde ! org>
Date:       2006-08-17 16:06:43
Message-ID: 20060817160643.GB9762 () ghostdog ! localnet
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thu, Aug 17, 2006 at 02:03:25PM +0200, Volker Krause wrote:
> On Wednesday 16 August 2006 16:53, Tobias Koenig wrote:
Hi Volker,

> >   1) second signal
> >   2) policy that statusChanged is emitted also when the statusMessage
> >      has changed, so the client has to ask for the new statusMessage
> >   3) providing a statusChanged( int status, const QString &message ) signal
> > instead
> >
> > /me votes for 3) ;)
> 
> Yep, 3) sounds good to me too.
Ok, i've implemented it in the meantime and will add support for it to
AgentInstanceModel later.

> > So far the state thingy seems to be easy because a resource can have
> > only one state. A bit more tricky seems to be the progress information
> > because the resource could provide information about two parallel sync
> > processes with the server.
> >
> > The question is, do we want such fine granular progress information and
> > if yes, how do we report them via dbus?
> 
> I'm not aware of a resource that would currently be able to do multiple 
> operations at the same time, so I don't really see a use-case for parallel 
> progress reporting.
Well, the imap resource might want to synchronize several folders in
parallel (that's done by kmail atm).

> Here are some other resource related issues I noted while trying to implement 
> a real resource:
> 
> - Resources need to know at least the top-level collection which is associated 
> with it. This wouldn't be a problem if the user couldn't rename any 
> collection at any time. 
> 
> My current idea here is to extend LIST by allowing the resource identifier as 
> reference argument to support listing of all collections associated with a 
> specific resource. This seems to be compatible with RFC 3501 and would also 
> be very usefull for syncing complete folder trees. The resource would still 
> need to listen to collection change signals to catch renamings though.
Hmm, I tink Till has to comment on this...

> - requestItemDelivery(): is it supposed to be sync or async? I assume the 
> latter.
Right, we should have a brainstorming session anyway where we sit
together and define which operations should be sync and which async.

Also we wanted to avoid sync methods as much as possible there are some
points where it doesn't make really sense, e.g. all the AgentManager
dbus calls.

> - There needs to be a way to set and modify collection mimetypes. We could 
> extend CREATE similar to APPEND, but we probably need a new command for 
> modifying existing collections.
Sounds good.

Ciao,
Tobias
-- 
Separate politics from religion and economy!
The Council of the European Union is an undemocratic and illegal institution!

["signature.asc" (application/pgp-signature)]
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


_______________________________________________
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/
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

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