[Kolab-devel] share documents in IMAP-folders in a filesystem-like manner

Thu Apr 26 10:39:08 CEST 2007

Hi Bernahrd,

thank for your thoughts about this. Ido some "TOFU" in this reply to rise just 
one question: Do we realy need client-side extensions for this?

I think no, all we wanted to have in the first place was a way to easily store 
mails and documents in one kind of folder. The great advanteage ist, that 
this is nearly IMAP-client independet.

The advantages of offline-Access are alway given if a mail client is 
available, not being able to change them offline through a file-system-like 
access is not a problem in my opinion (and may be implemented later).

Regards
Ingo

Am Donnerstag, 26. April 2007 10:13 schrieb Bernhard Reiter:
> Hi Ingo,
> Hi Gunnar,
>
> On Thursday 19 April 2007 11:43, Gunnar Wrobel wrote:
> > Ingo Steuwer <steuwer at univention.de> writes:
> > > Am Mittwoch, 18. April 2007 11:39 schrieb Gunnar Wrobel:
> > >> > We'd like to have a document and e-mail share, which would allow to
> > >> > access/save emails and documents (files like office-documents, pdf,
> > >> > CAD and so on) in one storage.
>
> still open to me would be how such a project would be modelled in terms
> of IMAP folders. To me it would be nice if there was a structure like:
>
>    - project 23
>                 - emails
>                 - documents
>                 - appointments
>                 - contacts
>
> The ACLs for the IMAP folders and the kolabGroupOfNames
> seem to be sufficient to manage this.
>
> Conceptionally I feel we need to keep an eye on the access permission
> management. Actually we have two sources of indentify management right now:
> a) the directory service
> b) the IMAP permissions
>
> If we add more components to the Kolab system,
> especially regarding document management,
> we need to be careful where to save the ACLs and how to administrate them.
> The good thing about b) is that an account owner (= email address owner)
> has good control, so users can do the management themselfs within a client.
> I like the philosophy behind it.
> On the other hand we cannot access this permission system easily from
> other applications. More back to the directory service? Good question.
>
> > >> > The idea is to store thoese documents as mail-attachements in IMAP
> > >> > folders. This would allow an access whith all IMAP-clients and an
> > >> > integration in existing Kolab-servers.
>
> With IMAP clients that can do caching, you have offline documents,
> which is quite nice. Technically this feature would mean that the
> filesystem would need to operate on the IMAP cache.
> Maybe a http://fuse.sourceforge.net/ driver for Kontact would do part of
> the trick. Doing a read-only access should not be that difficult.
>
> Adding write access is possible in principle as well, though given the
> semantics of emails I would recommend to have a special
> Content-Type: application/x-vnd.kolab.XYZ  for it, thus limiting this to
> special folders that only contain documents that can be changed.
> This leads into another interesting question: How much content management
> do we want? Access to old revisions? Authentic versions?
>
> Wikis have better revisioning.
> Distributed source code management systems like
> http://selenic.com/mercurial/ are well prepared to do this offline as well.
> Both seem to be weaker at the access control level.
> Typically a content management system would use a database which is good at
> access controls that are centrally managed, but bad for resource use and
> backups.
>
> How do we to the connection between the different aspect of the whole
> system? One typical way of solving this would be to work with unique
> identifiers, hash sums, signatures and encryption.
> If done right, this would even help with interoperability between foreign
> installations.
>
> > >> > What would be needed further is a platform-independed
> > >> > filesystem-mapping which should allow to open or modify at least the
> > >> > attached file from Windows an Linux. Possible solutions would be to
> > >> > implement an mapping for example as samba-VFS-plugin or to provide
> > >> > some WebDAV-Compliant access to IMAP-folders.
>
> For windows, the most capable Kolab offline client is Outlook with the
> connectors, so if you want file access offline the connectors would need to
> implement this. Otherwise online access is what you can get.
> Then you look into webDAV or CIFS access.
>
> > You would need to create an IMAP driver for the Horde virtual file
> > system that uses attachments as a storage object. This would not be
> > too complex I believe.
>
> Sounds doable to me.
>
> > > A possible workflow should be:
> > > 1) receive a mail with an attached file
> > > 2) move it into an IMAP-Folder
>
> Note that this semantic should allow later to write the file,
> so for archiving purposes this would not be good.
> Potentially I would say the contents of the email except the attachments
> will be gone. Also I believe it should be one attachment per email for
> starters.
> So this needs to be a special folder and the user knows that the email
> itself will get mangled badly.
>
> Hmmm, but then where to we place meta information about the file?
> Naturally in another email part. We would need to look for syntax and
> semantics for this.
> Would we want to preserve the information in the original email?
> Yes. But we do not want to save it twice ideally. So removing the
> attachment from the original email, replace it with a hash and save
> the attachment in an email-folders with files.
>
> > > 3) access the attached file in a filesystem-like manner (i.e. kpdf ->
> > > file -> open)
> >
> > This would then be possible with the VFS driver.
> >
> > > In this case Horde needs to be IMAP-client and WebDAV-server, but the
> > > later isn't implemented yet, right?
> >
> > WebDAV is available
> > (http://cvs.horde.org/framework/RPC/RPC/webdav.php) but one would need
> > to extend the Gollem API so that it allows remote access to its
> > procedures.
>
> For online access if webdav is enough,
> I see no problem doing it with the Horde libraries.
>
> The hard part is to do a design that is generally useful
> and coming up with syntax and semantic on the folders
> and the formats in there.
>
> I guess we should start a section in the wiki to document the design
> discussion and various ideas.
>
> Bernhard

-- 
Ingo Steuwer           Projektmanagement        steuwer at univention.de
Univention GmbH        Linux for your Business  fon: +49 421 22 232-43
Mary-Somerville-Str.1  28359 Bremen             fax: +49 421 22 232-99
                       http://www.univention.de