Christian Schulte wrote: > > Ken Murchison schrieb: > > >No. The domain level of the hierarchy is not treated as a mailbox. I'd > >have to think about whether this is even possible. > > > I got a bit deeper in the code and I think there are some things worth > to mention: > > >Every time I've made a big change to the mailbox naming/structure (altnamespace, > >unixhiersep, virtdomains), I spend several days thrashing on the > >LIST/LSUB code. > > > As I saw in the code adding a quota for a domain would really mean to > re-write a hole lot of code. The naming representation of mailboxes like > user/account@domain looks a bit "unlucky" to me but seeing the code I
It was done this way because domainnames are going to have "." in them which would _force_ people to always use unixhiersep with virtdomains, which seems unfriendly. Besides, when I was soliciting input, nobody complained. > know why things are the way they are ;-) Logging in as an admin things > would be better if representation would really be something like > /domain/user/account. I think it would be possible to create a domain It would, but its really isn't feasible for the reasons above. > with every IMAP-client without the need of having to run "mkimap -d > domain" buy simply creating the domain-"folder" with the client in the > root of the hierarchy. But that really means a lot of code-changes! As I It might be possible to have the necessary directories created on the fly. > saw the actual virtual domain support simply "copies" the underlying > storage-hierarchy so that every domain looks like beeing an own cyrus > installation. However this is not the desired way and the whole virtual > domain support looks a bit squeezed into the existing code. The best > solution to get a real tree hierarchy for virtual domain support would > make it impossible to use the "old" spooling code so by now I think it > is impossible to do the per domain quota with a quick and easy This was done because when I asked for input, people said that they wanted each virtdomain in its own (hashed) hierarchy. > enhancement of the existing code. I can live with not beeing able to > specify a domain-quota but what really drives me crazy is that I have to > mkimap -d domain for every new domain. So changing the whole spooling > mechanism would really bring advantages but it also means to re-write > the complete code which nobody really wants to.... I have been discussing this at length with Rob and it might be possible to get rid of mkimap (have directories created on the fly) and have per-domain quotas. This biggest problem here is that once again there is no incentive to do so. Neither I nor CMU have any (current) use for the virtdomain code. I did the current implementation because I got sick of hearing all of the bitching on the list about the lack of support. What bothers me most is that those people who can benefit the most from such support (eg, ISPs), don't seem willing to either pay for such support (either past or future work) or do the work themselves. (Fully expecting to get a bunch of flames at this point) Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
