[Kroupware] public folders (was: Re: Kroupware replacing Exchange)

[Bo Thorsen]

On Wednesday 05 February 2003 10:39, Henning Holtschneider wrote:
> --On Mittwoch, 5. Februar 2003 09:31 +0100 Bo Thorsen <bo@sonofthor.dk>
>
> wrote:
> >> 6. creating public folders storing calendar data, tasks,
> >> contact information and emails?
> >
> > I don't know what you mean by public folders. Do you mean uploading
> > all
>
> Did you *ever* see an Exchange/Outlook combo in action? I suppose, no
> ;-)

=46ortunately not *grin*.

No seriously, there are several cool features in Exchange/Outlook that I=20
would personally like to have too. But for 1.0, the feature list is=20
pretty much set. Development will carry on in standard KDE - the full=20
client will be a part of KDE 3.2. And expect the KDE guys to start=20
filling features in once it's usable. There are several developers who=20
are using Exchange in their dayjobs and they know the benefits of the=20
features.

> Public folders in Exchange are mailbox folders available to everyone
> connected to an Exchange organization. The folders will appear in a
> seperate tree of your Exchange mailbox an can be arranged in a
> hierarchical order. Access can be controlled through ACLs. All elements
> that you can store in your personal folders (email messages, contacts,
> tasks etc.) can be stored in a public folder, too. Additionally, you
> can feed Usenet news into public folders on the Exchange server.

This definately sounds useful.

> In theory, this works on the Kolab server, too. It offers public IMAP
> folders through Cyrus with ACLs. But at least  Outlook/InsightConnector
> (haven't tried the KDE client yet) can only store email messages in
> those public folders. You can circumvent this problem by creating a
> regular user on the server just for sharing. Additionally, public
> folders will not appear in a seperate "tree" in Outlook but simply at
> the bottom of your folder list together with folders shared by other
> users (see below).

Yes, as Tassilo replied in another mail, Kolab can do this. However, the=20
KDE client can't, so you won't get much from it.

In KDE 3.2 (actually in current cvs HEAD), the storage layer is more=20
separated from the individual parts than it is in kroupware_branch from=20
which the betas are taken. With this separation, the applications using=20
the IMAP storage layer can store any kind of text file in a folder, and=20
it won't be hard to implement binary files too. So technically there's=20
nothing stopping us from implementing this, but for now it's not done.

> Please correct me if I'm wrong, but AFAIK the bottom of the problem is
> this: the IMAP protocol specifies "public folders" as folders of a
> given user which are visible to others - nothing more. To make things
> more complicated, Cyrus introduced public folders on their IMAP server.
> On the server side, this is a public folder as we know from Outlook
> (i.e. it doesn't belong to a user) but the IMAP protocol has no way to
> distinguish between "shared" folders and "public" folders. I think this
> is why IMAP-derived developers like Bo have problems understanding the
> term "public folder" ;-)

This is exactly why it will "just work" with IMAP. The IMAP layer just=20
checks if it has the rights to down-/upload and then does it's thing. So=20
if I have read and write access to some folder, then I'm all set.

Or am I still missing some point here?

> At least our customers who are running Exchange are extensively using
> public folders to share company-wide information such as contacts and
> calender events (who is on vacation?). When switching to an IMAP-based
> system, this would be a big change for them :-/

Yes and no. We have the LDAP contacts working fine, so that's a=20
replacement for the shared folder (note: the LDAP IO slave in KDE 3.1 is=20
readonly, so uploading a new contact can only be done with the web=20
interface. I agree this is a problem. In KDE cvs, the slave is read/write=20
so you can save contacts directly to the LDAP server). Actually it's IMHO=20
even a better way to have contacts on LDAP than in a shared folder,=20
because you can get to them from other LDAP enabled applications too.

=46or the calendar events, I see your point. It would be cool to have a=20
company wide availability overview, perhaps even with different visual=20
appearence for people who are on leave, on vacation etc. Right now we=20
have the free busy lists, but they only show you when someone have free=20
time in their calendar. No distinction is made between unavailable and=20
busy. It might be that I'm wrong in one or two ways here: It's quite=20
possible that the iCalendar Free/Busy format specifies this type of=20
information to be available. It's even possible that KOrganizer already=20
publishes it. But anyway, there's no way to see a persons free busy list=20
than to start an invitation and put him in there.

I would suggest that you open a wish for KOrganizer in the KDE bug tracker=
=20
for this request. Or at least take the question to kde-pim@mail.kde.org=20
which is the mailing list for KOrganizer. I'm pretty sure they will be=20
interested in the feature.

Bo.

=2D-=20

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klar=E4lvdalens Datakonsult  |   Denmark