on 2/22/03 8:37 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> ----- Original Message -----
> From: "Kurt Bigler" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, February 22, 2003 10:53 PM
> Subject: Re: [sqwebmail] NEW: domainmap Patch
>
>> on 2/22/03 11:11 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
>>
>>> Howdy list,
>>>
>>> What does this patch do?
>>> ------------------------
>>> This patch adds functionality to sqwebmail. It allows the sys admin to add a
>>> file to the configuration directory
>>> (/usr/local/share/sqwebmail on my FreeBSD 4.7 system) named 'domainmap'.
[snip]
>> I still wish the logindomainlist and domainmap could be integrated into one
>> file. Compared to everything else, this is a minor issue, but any chance
>> this possibility is still open to discussion?
>
> Sure, it's still open to discussion. I'm not the type of person that
> entertains delusions of perfection.
>
> However, I really don't see the point. It would unnecessarily complicate
> things, IMHO. When programming, I try to group things
> logically, and the 'logindomainlist' file does something ENTIRELY different,
> and serves an entirely different purpose, than the
> 'domainmap' file.
>
> Why does having two separate files bother you so much? Perhaps if I knew why
> it was important to you then I could better understand
> your reasoning, or, at the very least, suggest a solution that might work
> better.
Two reasons.
One is that it really bugs me to have to have two parallel lists to
maintain. So far I am maintaining all my server stuff manually. I haven't
yet written scripts to do things like add a domain, partly because I don't
think I have enough experience yet to know how to create a good
general-purpose solution. Even if I do eventually write scripts to do this,
I would prefer if the scripts had to mess with fewer files to do their work.
The other reason is that I actually want SqWebMail to be as successfull as
possible (for totally selfish reasons), and I think it makes SqWebMail a
more complex product if two separate files are used. This complexity has
two aspects: the user experience and the implementation. By user I mean the
administrator, not the end user. The end user won't see the difference in
any of this.
Regarding the user experience, I suspect other user's experiences might be
simialar to mine. They will want something as simple as possible to
maintain. For most people who USE both the logindomainlist and domainmap
features (which I believe will sooner or later be the most everyone who uses
logindomainlist), these two files will look something like this (only much
longer):
logindomainlist:
domain1.com
domain2.com
domain3.com
domain4.com
domain5.com
domainmap:
webmail.domain1.com:domain1.com
webmail.domain2.com:domain2.com
webmail.domain3.com:domain3.com
webmail.domain4.com:domain4.com
webmail.domain5.com:domain5.com
Thus essentially the same list of domains is repeated 3 times in 2 different
files. 2 times in 1 file is much better. Maybe it is a typical thing for a
relational database (which I don't really know much about) to store such
information in a redundant way, with multiple tables and common keys
appearing in each. But then you want a front-end that completely hides this
from the user. And here we would certainly not want to create such a front
end.
Also, look at the file name "logindomainlist". To me, both of these files
are lists of domains that relate to login - they are both login domain
lists. I think this is a simple way of looking at things which I am
guessing other SqWebMail administrators might relate to, not caring about
the SqWebMail internals.
Regarding the implementation, I suspect an implementation which combines
these functions into a single file will actually be slightly simpler than
the current implementation. But I might be wrong, and need to look at the
code more carefully. It was just that my gut was telling me these two
things are incredibly intertwined. I am also not into obscure hacks that
make code smaller for the sake of small - it should also make sense from a
functional level. I should take a closer look.
However: I am not familiar with how the template-per-domain feature works.
If in fact, the logindomainlist is part of the configuration which would be
customized PER domain, where the domainmap is global, then this might be one
problem with combining the two.
But here is another thought: Suppose a server hosts domains for several
organizations, and each organization has several domains, with emails hosted
on each. End-users on this system might want to see only the domains in
their organization in the popup list when they go to login. This is a
situation that a per-domain logindomainlist could handle. However if you
think about it, this approach actually involves a LOT of redundancy. Much
better in that case if there were only a single logindomainlist, with a
column added to hold a group key. When creating the popup domain list
SqWebMail would list only the default domain for the particular web url, and
other domains with the same group key as the default domain.
This example also illustrates how knit-together the popup domain list and
the domain mapping are. The fact that I was thinking along this lines is
probably why I was seeing the two as belonging together from the start.
With a little more thought I can probably make a specific proposal about how
to combine domainmap info into logindomain list, just to make sure I don't
create any compatibility problems in the process, since Jesse brought up
this concern. But right now I want to take a break from thinking about it.
Maybe someone else will come up with something in the meantime.
By the way, getting just slightly off-topic: this is a great list. Maybe
there is just less ego here than a lot of other server-software-related
lists I have subscribed to at one time or another. Thanks to everyone here
for creating this welcoming environment. In this case thanks to Jesse for
being so open to discussing things. In my mind this attitude (or lack of
attitude) fits very well with what I think free software is all about.
-Kurt Bigler
> In any case, thanks for testing the patch!
>
> Jesse
