on 2/26/03 3:05 PM, Kurt Bigler <[EMAIL PROTECTED]> 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:
[snip] >> >> Great! If you can't think of any problems, and I can't think of any problems, >> then it might actually be a decent idea! I'm going to try to code it tonight. >> My boss is pushing me to finish this nonsense up! > > Actually, I didn't mean to imply that there were no problems elsewhere in this > idea. Actually I think it has gotten (to me) more complex by a factor of 10, > so that I can't imagine jumping into implementing it. It seems to me there > are several levels of new issues here. And with all the emails flying by I'm > not sure where all the issues stand. I would kind of recommend bouncing a > "final" spec around - a spec which includes all the features in one message - > until it truly becomes final. > > Lacking time to fully analyze what appears to me as all the outstanding > issues, and not sure even which issues have been decided, I will make a few > comments hoping to help in spite of my lack of preparedness (and time) right > at this moment. So this is kind of a scattered list of responses: > > I would be concerned about any implicit prefix being removed from HTTP_HOST. > It sounded like this was going to be done. > > 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. > > 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. > > 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. > > 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. > > 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? > > 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. > > (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, 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. > > * 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. > > 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. > > Thats all for now. I forgot to mention one other thing I was confused about. I want to make sure that the original * and @ functionality were both being represented in this new offering. Somehow that wasn't clear to me. It sounded like @ would do what * did, and * you were calling the wildcard modifier. Are you saying the wildcard modifier would enable the interpretation of wildcards? If so they why is this needed rather than simply the presence of the wildcards themselves? We aren't worried about domain names containing *s are we? (Sorry if I read things too fast.) > > -Kurt Bigler
