Hi Milan,

Am Mittwoch 14 September 2011, um 08:25:20 schrieb Milan Crha:
> On Tue, 2011-09-13 at 15:56 +0200, Christian Hilberg wrote:
> > * IMAP ACL management. A new tab (or something alike) when
> >   right-clicking an IMAP folder in the Evo folder tree to view and
> >   edit IMAP access control lists as defined in RFC 4314 [4]. The IMAP
> >   ACL functionality will be implemented on a new branch based on A-B
> >   (see "Phase I, (1)"), much the same way ANNOTATEMORE has been
> >   implemented, to the extend needed for Kolab. This will lead to an
> >   API extension (like there already is in evolution-kolab-IMAPX).
> >   There will be the need to extend Evolution as well, as to make it
> >   use this API extension. It is currently not yet planned exactly how
> >   this can be done without littering Evolution with "the tacking on of
> >   arbitrary features" (MBarnes, [3])
> >   (Kolab specific: no)
> 
>       Hi,
> see how evolution-exchange provides the same functionality of Folder
> Permissions, it just adds a popup menu item and servers all what is
> needed without any special modification on evolution side. The same
> should apply for the folder type annotation editing - no change on
> evolution should be needed.

I'll check that. The less change needed on Evo side the better. I'm not
sure yet exactly how we will be able to solve it. I do not have knowledge
about how folders are handled in Exchange, but for Kolab, it is IMAP - so
we need the capability for IMAP ACL, which, unless I'm mistaken, IMAPX does
not yet provide. This part will be done (for now) in our IMAPX derivative,
and Evo will need to make use of this functionality one way or another. ACL
management is not limited to the evolution-kolab backends and is needed for
the Kolab email folders (which are plain IMAP folders) as well. Maybe
we can do this in an EExtension, I'll check with evolution-exchange. If
the UI extension evolution-exchange provides is fine for the Evo community
(which I think it is), then we could try to mimick the layout in order to
try for a consistent user experience. To that respect, maybe it will be
possible to iron out some common approach for the groupware plugins that way,
which I think is what Matt has in mind.

> With respect of creating a new folder on the kolab server other than
> mail: when you do File->New->Calendar and select the Kolab group, is it
> able to create a new folder and annotate it accordingly to the source
> group? Evolution-mapi provides a short folder list with folders of the
> certain type from which user can choose and under this is created the
> new calendar (or address book). Again, no change on evo side is needed
> for this.

As far as creating new PIM folders goes, this is correct. This can be done
entirely in the backends, provided we can re-use existing account information
(which in current Evo/E-D-S should be possible).
  Things are different when you need to change or set the type of an existing
folder manually. This is for error recovery mainly, but has been described by
our sponsor as a real life scenario which from time to time happens to occur
(due to server failure or client error). To do this, it will be made possible
to display the PIM folders in the email folder tree (though these folder's
contents will not be accessible), so you can right-click the folder and edit
the annotation it carries by selecting a type from a drop down list. This is
the typical way Kolab clients will provide this functionality for the user.
There are a number of issues related to this, e.g. the kolab backends need to
be notified of the change do they can sort of "drop" a folder they are no longer
supposed to care for ... whether or not we can sanely implement this remains to
be seen. The goal behind this is to enable Evolution to act as a complete Kolab
client, removing the need to resort to different clients to get all tasks done.

Kind regards and thanks for the hints,

        Christian

-- 
kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to