on 2/23/03 8:18 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote:
[snip]
> Kurt Bigler wrote:
>> One is that it really bugs me to have to have two parallel lists to
>> maintain.
>
> I'm still not convinced that it's that big of a deal. I agree partially with
> you about the name of the file, and the fact that users
> will probably like to have everything in one place, and that it's a bit
> redundant.
>
> I suppose the fact of the matter is that it was easier to implement it in a
> separate file. But I could just as easily incorporate it
> into the 'logindomainlist' file.
>
> Tell you what:
>
> I still haven't heard Mr. Sam's opinion on my patch. I don't know if he loves
> it or hates it. (I would imagine that he'll like it,
> though. It adds some well needed functionality.)
>
> Sqwebmail is his baby. Let's let him decide. If he likes it better in one
> file, I'll happily rewrite the patch. No big deal. If he
> likes it better separate for compatibility reasons or whatever, then I'll
> leave it be and write some documentation in preparation
> for including it in the distribution.
[snip]
I want to stay active in advocating that while these new features are being
considered, that they are considered in the broadest possible way. I'm a
little concerned that if we wait a few weeks as Sam suggested, that by that
time there will be so much invested in the current approach that there will
be no going back.
I'd like to find a way to eliminate the redundancy which was my main concern
about the current solution (as implemented in Jesse's patch) for those of us
who will be using both the domainmap and logindomainlist feature, while
keeping the solution user friendly for all kinds of use. My original
proposal regarding combining the domainmap information into logindomainlist
(in a compatible way) might have made it slighly more complex for people who
would have otherwise used domainmap alone (using Jesse's existing patch).
My past messages went into a little detail about 2 or 3 possible ways that
domainmap and logindomainlist could be combined. I'd like to bring these up
again to fully clarify what I mean, but just as "possibilities" because I
really don't want to draw conclusions too quickly about what is the best way
to structure it.
I also have my suspicions that some people might be needing somewhat more
flexibility than the current patch solution offers. This was reinforced by
Jesse Cablek's recent email when he wrote:
> I personally would prefer to keep this separate. Then hosted users
> wouldn't see a dropdown list for my personal domains, and vice versa.
Even though Jesse C. is happy with a solution that does not involve a popup
list of domains, it seems very likely that there will be others who like the
popup domain list who would also like to have some separation, possibly
having different lists of domains come up when different webmail urls are
accessed.
So here is one possible solution, tentatively rolling everything together
into the logindomainlist file. This is basically my original idea, and
retains its possible disadvantages - i.e. it might be slightly more
difficult for those who would have used domainmap alone. But let's not
worry about that now.
In this proposal logindomainlist would have records of this form:
login-domain:web-domain-spec:group-key
The first two fields are exactly the reverse of the domainmap fields as
currently defined.
Fields:
login-domain
is the default domain for the login, which works either with or
without a popup list, as already described.
web-domain-spec
is a string to match against either the SERVER_ADDR or HTTP_HOST
environment variables (for IP- or NAME- based virtual hosting)
group-key
is either:
an asterisk, indicating that this is a "loner"
domain - the popup domain list should be suppressed
or:
a string used to identify a "group" to which this domain belongs
All domains sharing the same group-key will appear together
on a popup domain list.
The group-key field may be empty. The "empty" key
is a valid group-key like any other. All domains
specifying no group-key belong to the same group.
Some possibilities for use of this scheme:
(1) If you want ONLY logindomainlist functionality, you use logindomainlist
exactly as it has always has been used. In this case the web-domain-spec
and group-key fields are omitted - the colon field separators are therefore
not needed.
(2) If you want ONLY "domainmap" functionality, the logidomainlist file
might look like:
domain1:webmail.domain1:*
domain2:webmail.domain2:*
domain3:webmail.domain3:*
Here the * disables the popup list, allowing the domain mapping
functionality to be retained.
(3) If you want to use both the popup list and domain mapping, so that the
popup defaults intelligently, then logindomain list might look like this:
domain1:webmail.domain1
domain2:webmail.domain2
domain3:webmail.domain3
(4) If you want something like (3) except that domain3 should not have the
popup list, then:
domain1:webmail.domain1
domain2:webmail.domain2
domain3:webmail.domain3:*
(5) If you host 2 different organizations, and also have some personal
domains, it might look like this:
personaldomain1:webmail.personaldomain1:personal
personaldomain2:webmail.personaldomain2:personal
org1domain1:webmail.org1domain1:org1
org1domain2:webmail.org1domain2:org1
org2domain1:webmail.org2domain1:org2
org2domain2:webmail.org2domain2:org2
That way each users from each organization see only that organizations'
domains in the popup list, and you also keep your personal domains separate.
I hope that clarifies what I was intending. This is one example of how a
broad range of possibile configurations can be handled in one file, also
offering a grouping feature that the current two-file approach can not
handle.
In terms of implementation, the code in sqwebmail.c can be very similar to
what Jesse has already done to support domainmap and logindomainlist. There
are currently two loops - one currently loops through domainmap to determine
the default domain, living in the new function get_defaultdomain. The other
loops through logindomainlist to build the popup. One way to implement the
above suggestion is to simply change both loops to loop through the same
file. The file could be opened once and scanned twice, reducing overhead a
little. get_defaultdomain would become get_defaultdomain_and_groupkey. It
would return the info needed to control the buillding (or not) of the popup.
The groupkey would be used to filter the popup items. The defaultdomain
would determine the default popup item, as now. If groupkey is * the popup
is suppressed, and the default item becomes the hidden field, as now. The
already open FILE * variable can be passed into
get_defaultdomain_and_groupkey, and subseuently re-read from the beginning
again when building the popup (if needed).
There are other possibilities. But I thought it would be helpful to present
this possibility clearly for everyone's review.
Thanks,
Kurt Bigler
