15.11.2015 17:40, Alex Peshkoff wrote: >> Ok, but you said that every reload of databases.conf will lead to >> creating of a new >> >config object instance, right? Why? > Certainly it's implementation detail, but I've wrote that code and for > me it's the easiest way to support per-DB configuration.
>> But no, I don't call it "plugin architecture", I call it "implementation >> details". They >> are the same, no matter what config interface you are, and here no "one size >> fits all" >> solution. That's why I say "simpler is better". > > What may be simpler then store whole interface (provided you need it > later certainly)? One addRef() or just RefPtr. A singleton config manager which refresh its internal structures on signal/timer/request/etc. It requires no efforts from an user (plugin programmer) at all. >> Yes. But aliases.conf had a very simple structure and was used only by >> Y-valve. >> Databases.conf is much more complex and may contain parameters for many >> plugins (which is >> another mistake, IMHO). > > Some parameters are used by many plugins and yvalve itself. I prefer to > treat them as server parameters to which plugins certainly may have access. That leads to a mess and problems if several plugins need a parameter with the same name but different meaning or value. For server and client auth plugins it already happens and you have to rename one parameter. WireCrypt is another rake that is just waiting someone to step onto. > I agree that with firebird.conf situation is really bad. Historically > it's a mix of parameters specific for engine, yvalve network listener > and even network client. > Reloading it is real pain. IMHO, simple tossing parameters into engine12.conf, remote.conf, etc. may clean the mess a little. -- WBR, SD. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
