On 11/15/2015 07:23 PM, Dimitry Sibiryakov wrote: > 15.11.2015 16:53, Alex Peshkoff wrote: >> On 11/15/2015 06:25 PM, Dimitry Sibiryakov wrote: >>>> 15.11.2015 14:22, Alex Peshkoff wrote: >>>>>> Use of permanent >>>>>> interface is not an option here - configuration for module may change >>>>>> during server lifetime, and creating new and new permanent instances >>>>>> means memory leak. >>>> Here you imply that plugin must see configuration files in state they >>>> were at the >>>> moment of its initialization >> In some cases - yes, in others - not. >> >> An example - engine works with permanent copy of firebird.conf taken >> when it was started, but aliases.conf (or databases.conf) are reloaded >> when changed. > 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. >> If you call a way to store parameters (one by one or as a whole >> interface) to be a "plugin architecture" I'm very sorry... > Parameters worth nothing by itself, they are used to form something new, > or change > internal state of plugin. And this new thing (for example, transaction log > file name) > should be stored somewhere anyway. > 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. > >>> If user changed configuration files, plugin may be interested in it, >>> or not, but >>> currently there is no way to inform it. Actually, whole server has no ass >>> to be kicked to >>> reload configuration files. >> Yes? Are you sure? aliases.conf was simply re-read for each opened >> database since it's arrival in fb1.5 > 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. > Some of these plugins couls like to know about parameters change > sooner than at the next connection. > With firebird.conf situation is even worse. In it is gathered > configuration for many > different plugins (for historical reason), but if user change some of them, > he has to > restart whole server. 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. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
