On Wednesday 26 February 2003 18:05, Kurt Bigler wrote: > on 2/26/03 2:10 PM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > > On Wednesday 26 February 2003 16:40, Kurt Bigler wrote: > >> on 2/26/03 8:38 AM, Jesse Guardiani <[EMAIL PROTECTED]> wrote: > >>> ----- Original Message ----- > >>> From: "Jesse Cablek" <[EMAIL PROTECTED]> > >>> To: <[EMAIL PROTECTED]> > >>> Sent: Wednesday, February 26, 2003 10:51 AM > >>> Subject: Re: [sqwebmail] new file proposal > >>> > >>>> Jesse Guardiani wrote:
<snip> > I would be concerned about any implicit prefix being removed from > HTTP_HOST. It sounded like this was going to be done. Not removed from the environment variable itself, but from a temporary variable that contains the contents of HTTP_HOST. It's just wildcarding. I look for a match at the beginning, and remove it, then I look for a match at the end, then remove it. If nothing matches, nothing gets removed, and if nothing gets removed, then it doesn't fit the wildcard. > > There were some things that it struck me are much less orthogonal than they > could have been, regarding handling name-versus-IP-based hosting. The > previous approaches have so far been totally symmetrical. IP hosting doesn't need funky rewrite rules. It's simple and clean. You specify an IP, and you're done. If someone wants to write wildcard functionality for IPs in the future, then they're welcome, but I plan to use vpopmail to handle this. ( thus the *vpopmail modifier ) > > I like the idea of using single characters rather than fully-spelled-out > options, i.e. v rather than vpopmail and a rather than allvirtual, because > that allows for any combination of options to coexist when they can. > Otherwise I think they should be separated by spaces or some other > delimiter. debatable. characters are easier to type and full names are easier to read. I'll make it easy for this to go both ways, seeing as how I don't care. > > Some of these options deal with setting environment variables. I seem to > recal someone suggesting another environment variable need that I don't > recall being addressed in the current set of options - but I'm not sure. > Anyway what I'm getting at... now I have to start thinking out loud - so > don't just anything until I finish because I think this is leading > somewhere. This is a recap of my train of thoughts about this... > > So rather than having implicit environment variables, why not let people > just give the name of the environment variable to be set. This would allow > people to set variables in custom ways depending on the domain matching > process. Yes, well, I AM in a hurry, so maybe everyone could do me a favor and be greatful for the code I have provided and allow me to have my *vpopmail modifier. I would really appreciate it, as would many other vpopmail people I'm sure. The whole 'modifier' interface is modular enough for me right now. If someone wants to write a new modifier in the future, they just add a new if statement in my code and start writing. No big deal. > > Now some commentary... the whole reason this line of thinking came up is > because it sounds like a bunch of special cases are being introduced, in > spite of a potentially very general option syntax, each option is doing > something special, involving hard-coded values (e.g. names of environment > variables). So that's why I wanted to generalize it, but then the > generalization almost leads to putting a little scripting language inside > logindomainlist, and there is NO END to where that leads. The potential > categories for options and what they do (besides setting variables) could > go on and on. That's my point. At least for now the new features will stop here. I think the drafted functionality will work for 98% of the community, and if someone comes along who needs something else, they can write their own modifier hook. I only have so much time guys. Sorry. > > Regardless of which approach, you might be introducing here a "platform" > that creates the need for repeated additional enhancement in response to > yet-unforseen needs, on all too regular a basis. > > Did you notice the level of the new buzz of ideas that has arisen today? Yes. I'm greatful. > > This suggests to me 2 things: > > (1) This is no time to start implementing. Better to get back to work and > return to this in a week. Otherwise it is likely you are just creating > more work, and whatever you do now will become the defacto state of things > because you will have run out of time to do more. I for one don't believe > I have assimilated a third of what went by today. So if you go ahead you > are going without whatever benefit my full understanding might offer, for > what its worth. On the contrary, we have a good thing going here, and it's very extensible. I don't want people thinking that I'm going to start writing a logindomainlist language, because I'm not. It's good now. If we think of something that is even better before it's release time, then I might implement that too, but it has to stop somewhere. Things I can see being added in the future? Database hooks to replace logindomainlist. The logindomainlist file is getting searched twice right now for every login. I'd bet that it'll start bogging the system down after about 1000 entries. Database functionality is the next step, IMHO. > > (2) It would be good to put a "cap" on the degree of potential enhancement. > One very satisfying way to put a cap on this, Done. I implement this, then I'm off to work on some other projects. > is I think to provide a > "hook" so everybody can get what they want without your ever needing to > enhance this again. Here are two possible hooks that I can think of: > > * If logindomainlist is executable, execute it. Execute it honoring the > mechanism used by shells, honoring the initial #! line. The entire cgi > environment gets passed into this executable, plus arguments or more > environment variables for additional info that is available to SqWebMail, > if needed. This executable can be written in perl, shell, C, etc. It can > set environment variables to its hearts content, log webmail logins, you > name it. It can do all the things that logindomainlist would have done as > a text file, by using if/else logic. It can do all the things that > otherwise you would be tempted to create another patch to do. (Actually I > guess as a child process it can't create environment variables that are > passed back to you - is that right? If so it could still write to standard > output the needed information.) In any case having this hook allows you to > avoid indefinite proliferation of enhancements. Perhaps it even allows you > to dismiss some of the ideas just proposed, and simplify what you were > about to approach doing. No. I'm not going to implement a programming language. Why would I? I just did all of this work?!? And it works fine. You'll live without a CSH extension. > > * The other possible hook: the logindomainlist text file contains a field > (maybe another field, maybe just part of the modifier field) with the name > of an executable file which can then be determined by the domain matching > logic. It could do the same kinds of things as the "main" logindomainlist > executable, except driven by the domain matching logic. This can be implemented in the future via a new modifier hook. But not by me. > > Ok, this was pretty raw, but I have to go. I hope you haven't started > implementing already! I hope some of these ideas might save some trouble. Uhhh... sounded like you were trying to convince me to write a programming language for domain mapping. You call that saving me trouble?? :) I know you meant well. Thanks for the comments, Jesse > > Thats all for now. > > -Kurt Bigler -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net We are actively looking for companies that do a lot of long distance faxing and want to cut their long distance bill by up to 50%. Contact [EMAIL PROTECTED] for more info.
