[prev in list] [next in list] [prev in thread] [next in thread] 

List:       info-cyrus
Subject:    Re: Feature proposal
From:       Michael Fair <michael () daclubhouse ! net>
Date:       2001-09-28 9:07:16
[Download RAW message or body]

While I can appreciate the feature you are trying
to implement, the proposed implementation is..
well... limited.

For instace how do you give access to sfLocationA 
to mbUserG?

I'm envisioning a use for this where Shared Folders
are "mailing lists" for projects at a company.

You have a set of people, and each person can
subscirbe to the Shared Folder of the project
they are working on.  I use the term project loosely
as it represents any group a person might be
involved in like their department, or the 
emeergency response team.

In your proposal, the nature of the Shared Folders
being added and removed often as projects come
and go is extraordinarily cumbersome becuase users
mailboxes have to be continuously moved around.

Further, how do you have a manager for more than
one project without giving all members of those 
projects access to the other shared folders.  What
do you do if you have UserA on ProjectX and ProjectY, 
while UserB is on ProjectX and ProjectZ.

In reality, the current architecture seems to
most closely resemble the real world.  You have
a set of users, who have access to a separate set
of Bulletin Boards.  You have control over which
users have what level of access to each of Bulletin 
Boards and while doing an "lm" ends up being very
unhelpful because of the large list of mailboxes
that come back, it is the most logical and straight
forward way to achieve the desired feature set.

One useful thing I am gleaning from your post is
a more conrete way to implement virtual domains.
Currently Cyrus has a single rooted Heirarchy.
One very useful feature for many of us having
to manage multiple domains would be a multi-rooted
tree so that the "Shared Folders" of one domain
didn't "bleed over" into another domain.  Currently,
the only way that I can see to implement this
without globally managing the ACls is to run 
multiple master processes with different configuration 
files (or a similar "jail" environment to create the
separate mail stores).

I would suggest looking at taking the Alternate 
Namespace patch to a next level, where any folder 
can be exported anywhere in heirarchy.  So the shared 
folder,/company1.dom/SharedGroupingA/Shared1 can be
exported as /Shared1 similar to the way the subfolders 
of Inbox are exported as if they were at the top level.

I would also like the ability to create separate
heirarchies, where upon user login they get relegated
to particular subtree as their root directory to
create the closed shared folder environment for
virtual domain support I mentioned above.

Neither of these seem like a trivial patch, but
might be worth looking into.

-- Michael --

On Sun, 2001-09-23 at 06:04, Norbert Sendetzky wrote:
> Hi all
> 
> In this message I want to describe a feature I think it's worth 
> discussing. AFAIK no other imap server currently implemented anything 
> like this (please correct me, if I'm wrong).
> 
> Until now, the mailbox system of Cyrus imap is more or less flat. 
> There are numerous mailboxes of users and public folders one level 
> below the root mailbox (this one you see if you connect as 
> administrator), which can contain subfolders. This is why I called it 
> "more or less flat". Users are only known to the imap server, if 
> there is a mailbox below the root which belongs to them. There is no 
> such thing as automatically generated shared folders for all or 
> groups of users.
> 
> My suggestion would be that mailboxes can be part of a mailbox/shared 
> folder tree. Two examples (sf* are shared folders and mb* are 
> Mailboxes):
> 
> sfAll
> -mbUserA
> -mbUserB
> -mbUserC
> 
> sfAll is a shared folder for all mailboxes below (mbUserA, mbUserB, 
> mbUserC).
> 
> 
> Now a more complex one:
> 
> sfAll
> -sfLocationA
> --mbUserA
> --mbUserB
> -sfLocationB
> --mbUserC
> --mbUserD
> --sfDev
> ---mbUserE
> ---mbUserF
> --sfTec
> ---mbUserG
> 
> sfAll is a shared folder for all users (A-G), sfLocationA for mbUserA 
> and mbUserB and sfLocationB for C-G (and so on for sfDev and sfTec). 
> All nodes in this tree are therefore shared folders and all leafs are 
> mailboxes.
> 
> The user mbUserF can for example post messages into sfDev, 
> sfLocationB and sfAll and can therefore reach all people below the 
> level of the shared folder he posted.
> 
> I hope I clarified my suggestion and appreciate any comments.
> 
> Regards,
> 
> 
> Norbert

[prev in list] [next in list] [prev in thread] [next in thread]