| Thread Previous • Date Previous • Date Next • Thread Next |
Hi Kay, thanks for your reply.
On Fri, Jan 16, 2009 at 8:12 PM, Kay Röpke <Kay.Roepke@xxxxxxx> wrote:
> Hi!
>
> On Jan 16, 2009, at 8:58 AM, Joshua Zhu wrote:
>
>> Hmm... convenient option.
>> However, the length of MySQL Proxy's command line is getting longer
>> for a user to type (given a few backends to set), not only because the
>> options have only long names, but also MySQL Proxy can be armed with
>> many plugins which may import more options.
>
> I agree, it's getting out of hand :)
>
>> Two suggestions:
>> i) Treat the configuration file as the right place where options
>> should be set (I know MySQL Proxy _does_ support this). At least tell
>> people this is the recommended way. When MySQL Proxy has some _rules_
>> to set, this will help.
>
> Not sure what you mean by "rules", but generally I tend to use different
> config files for testing different things.
> Much more convenient and less repetitive especially for the array options,
> like backends.
>
Sorry for not making it clear. The "rules" I meant were things like
rewrite rules, ACLs, ..., etc. Or these should be implemented as
application (lua script) settings, as you pointed out?
> One convenient thing to note here: Using both a config file and giving
> options on the command line will cause the command line stuff to override
> the config file. Very helpful for increasing the log-level for example :)
>
>> ii) Use Lua as the configuration language, which is more flexible and
>> more powerful than GLib's GKeyFile.
>
>
> I really don't want to allow people to use a programming language as a
> config option, mainly because I've seen some horrible stuff happen when they
> figure out they can write actual code in there :)
> config should be for settings only, and application (== lua script) settings
> are already in the script, which sometimes is not pretty either.
>
No, we don't need step that far :D By using Lua, the items in the
config file would be well structured at least, e.g:
backends = {
{ host = "192.168.0.1", port = 3306 },
{ host = "192.168.0.2", port = 3306 },
{ host = "192.168.0.3", port = 3306 }
}
But maybe my ideas were a little over designed :) Frankly, the
solution in MySQL Proxy now is okay.
> What use case do you have in mind? Off-hand I can't see the need for
> scripting the proxy/chassis options, but maybe I'm overlooking something.
>
No idea yet, perhaps things like "if client == somehost then set
backend = somebackend"? But again, maybe these should be implemented
in the application.
> In the end, I think we need to come up with short names for the most often
> used options, although there is the danger of colliding short names from
> different plugins.
IMHO, it's a non-issue, since we can give the user an error message
and then exit, when given two same short names.
> I'd like to think it would pick the first occurrence, but in fact I'm not
> sure what will happen.
>
> I've included it here:
> https://blueprints.launchpad.net/mysql-proxy/+spec/chassis-short-option-names
>
Wonderful, hope this can be done in the future :)
> cheers,
> -k
> --
> Kay Roepke
> Software Engineer, MySQL Enterprise Tools
>
> Sun Microsystems GmbH Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
> Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
> Vorsitz d. Aufs.rat.: Martin Haering HRB MUC 161028
>
>
Joshua Zhu
http://blog.zhuzhaoyuan.com
| Thread Previous • Date Previous • Date Next • Thread Next |
