Re: [Firebird-devel] Plugins and providers

[Adriano d. S. F. <adr...@gm...>]

On 26/10/2010 08:27, Nando Dessena wrote:
> Adriano et al,
>
>> Do you get the idea? Transform files to strings, and locate these
>> in-memory (or resource) strings as default configuration. In Windows
>> we could embed the file directly so users can replace them with
>> resource editors.
> Sorry for jumping in; I am going to get back to lurking mode right away,
> but there's a question that's popped on my mind: where does this idea
> that users want to change defaults come from? Defaults are by definition
> what you get when you don't change parameters. Users want to change
> parameters. Even VARs are fine with changing parameters (I've worked as
> an InterBase VAR for a long long time). As a user, here's what I would
> like to be able to do:
> - set parameters through a text-based config file for the normal case, and
> - set them through an initialization API call for the cases in which I
> need them to be hidden, or dynamic.
>
> I don't mind that defaults are hard-coded or included as resources or
> whatever, as long as I can set parameters. I don't mind about resource
> editors as well. A resource embedded into an executable is static, an
> API call is dynamic. Even a text-based config file is more dynamic.
> Embedding a resource looks like the worst of both worlds without the
> best parts to me. You are free to use it as a tool to keep defaults off
> the code (which is debatable anyway, but anyone gets to choose her own
> development style), but if I was you I wouldn't expect people to really
> use them. Changing executable files also has the effect of disrupting
> CRCs and alert virus scanners.
>
> Please ignore this message if it's regarded as off-base.
I told one *could* use it, not that it need to use. So if you don't, use 
what you need.

I'm just in favor of embedded default config as text because it's much 
more natural and something we should support.

You said about configure programaticaly. Since our current config is 
sometimes structured, it seems an API where you could pass a block of 
config text is ok. And this block shall override what's already 
configured, as well an explicit file would override the internal config.

So we know our defaults, then it's much easier to use the same approach 
internally. No need to write defaults in source code directly.

If the resources is not going to be used, then we can do the same in all 
platforms. I think as resource makes the Windows build easier, anyway.


Adriano