Some input to the format documents.

[Tarjei Huse]

Hi, 

I had a nice discussion with Bo on irc here the other day, and I've also
read the kolab2 format document. Based on this, I got a few suggestions
for input and discussion:

Documents as emails
I'd like to see a container for documents. I suggest that each document
is an empty email with attachments - preferably one per email and with
the name of the document as the subject. 

Reasoning: 
1) The more you can put into one repository the better. Today Kolab is
structured so that your documents will have to reside another place -
they don't have to. This will make it easier to use Kolab as _the_
document store.

2) The format must be in such a way that an simple imap-client can read
the files. I think this is more important here that wrt calendarfiles
and notes ++ because those parts it is more relevant to contain in the
users own mailhierarcy - while the documents and mails will often be
stored in shared folders. Also, there is no reason to add the complexity
of a propritary format to something that is allready defined in the
IMAP-rfcs.

Folderlinking
You should have a format for adding links between folders and other
objects. This could be used to link f.x. projects to a spesific folder.

Projects.
You should consider adding projects as a possible resourcetype that may
contain links to other kolabobjects like tasklists (one folder?), files,
members and addresses.

Addresses. 
A sad thing about moving addresses into imap is that few other clients
can read them. You should have a way to move addresses into ldap. 


Horde as the prototypeclient.
A concept that goes on top of the formats you discuss here, is the usage
of the webmailclient horde for format prototyping and development.

There are already ways to use kerberos or a Windows Domain login to
authenticate into a apache website. Using this, the user only has to be
logged into the network to access the Kolab hordesuite.

Using, this, one could see ways to produce applications first in Horde
and then other clients could implement support for the same formats
afterwords as this would take more time. Also, you could generate a
linkformat so that if the user followed a link to an object not
supported by an app (say a timesheet) the user could just follow the
link to the website and edit it there.

These are not finished thoughts, but I'd like to hear what you think
about them.

regards
Tarjei





-- 
Tarjei Huse <tarjei at nu.no>