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

[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


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20070426/74915eb8/attachment.sig>