On 09-01 23:08, Michael Graff wrote:
Using multiple domains in one server is pretty hard.
Was in 0.8.10, will be not in the next release.
The schema even fights with me. I can't have both "graff" in the "isc.org" domain and "graff" in the "flame.org" domain, for instance, at least with the same user name. I think the unique field there should be a <user, domain> tuple. Additionally, all tables should probably grow a domain column, and lookup() would take that as an argument (defaulting to the host-portion of the URI, probably)
That also makes things easier on routing rules, and on aliasing, and on user interfaces, at least IMHO.
Are there any plans to make this sort of thing much easier? If not, I may decide to hack on it a bit and see what I come up with.
It's done already. The next release will be extended exactly this way.
The reason why we originaly implemented it this way was that it is easy to compare just usernames. Domain comparision requires unification of the domain which is slow and hard to do. So, in 0.8.10, you can still have multiple domains but each domain must be kept in a separate table (which is doable because save and lookup functions accept table name as a parameter).
The drawback of this approach is that you must write complicated regexps to distinguish domains in the script and call save or lookup with appropriate table name. That means you have to modify the script and restart ser if you want to add a new domain.
Somebody already complained about it, so we extended the tables and unique key is now username, domain. That means, it is possible to store multiple domains in a single table, there will be no need to add new tables for new domains and adding new domains could be done on the fly without restarting ser and changing the config file.
Digest authentication was also extended to support better handling of multiple domains.
Of course, I'd also like to replace the scripting language with embedded Perl, but... :)
Why ?
Jan.