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

Thu Apr 26 12:52:18 CEST 2007

Hi Bernhard,

thanks for sharing your thoughts on this.

Bernhard Reiter <bernhard at intevation.de> writes:
> 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.

I'm definitely in favor of the ACLs on the IMAP folders. If a client
is smart enough to handle data storage in an IMAP system I'd say it
should also be able to handle permission on the IMAP folders. Maybe I
did not get the exact scenario you had in mind and where LDAP might be
better suited.

>> >> > 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.

Absolutely. Though this is certainly less funny than caches for Kolab
objects. Users could easily get the idea to store a video collection
in their mail folders which might be too much for the system. It might
be good to have configurable size restrictions for the files.

> 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.

I don't get what FUSE would do in there? Maybe you can elaborate?

> This leads into another interesting question: How much content management 
> do we want? Access to old revisions? Authentic versions?

Revision management would be a job for the client. But I think this
would be advanced stuff and if there is one client that cannot handle
versions, it would simply display all available attachments with their
versions.

>> 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.

Actually toyed around with that yesterday. It is not really hard
though I still need to get the concept of email attachments in sync
with filesystem ideas of dirs and files.

>> > 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.

Hm, I'm not convinced. This would require new client features and only
clients with these specific features are able to handle email
attachments then. But every email client around already knows how to
handle attachments. So I think it would be much better to adapt to the
already existing concept of attachments rather than creating a new
definition that can only be handled by Kolab specific clients.

I understand that this might make it hard if not impossible to
implement more complex aspects of document management. But to be
honest I believe people should use systems specifically written for
the task rather than handling their documents in attachments.

>> > 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.

As mentioned I already started toying around with hacking this into
Gollem (Horde file manager) since I had a use case for myself. I have
been using a document management system for invoices I am getting but
it is clear that this was too much for the task at hand. I do not need
versioning or metadata on these invoices. But it did also annoy me to
keep them just in the IMAP system since I still need to open every
email to get to the attachment if necessary.

The discussion with Ingo made me realize that this is actually not too
hard to simplify via Gollem. So I created a very simple Kolab VFS
driver that has only read capabilities at the moment. You can see the
result in the attached image.

The driver accesses only specific folders (marked with the Kolab type
"file") and searches all messages for file attachments. It then lists
the files prepended with the message UID. That is pretty bad but I
could not yet decide if a mail is a folder or not. It currently only
allows read access but it is a neat way to handle files within the
IMAP system.

The driver is here
(http://projects.pardus.de/kolab/browser/horde-cvs/framework/VFS/VFS/kolab.php). It
is really nothing more than a hack but maybe also provide a basis for
discussions.

Cheers,

Gunnar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gollem.jpg
Type: image/jpg
Size: 30059 bytes
Desc: Gollem
URL: <http://lists.kolab.org/pipermail/devel/attachments/20070426/35fd4c8d/attachment.jpg>
-------------- next part --------------

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

    >> Mail at ease - Rent a kolab groupware server at p at rdus <<

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium