On 03/21/15 17:46, Adriano dos Santos Fernandes wrote: > On 21-03-2015 05:52, Dimitry Sibiryakov wrote: >> 21.03.2015 2:18, Adriano dos Santos Fernandes wrote: >>> All these constants are mixed in the same number space. >>> >>> So we say we support multiple providers, but at the same time we expect >>> that all providers has identical FB-engine features? >>> >>> How do non-FB providers may have they own functionality with DPBs? >> Any provider (including Y-valve) must skip parameters it is not aware >> of. This way >> Y-valve can passthrough specific parameters to third-party providers. >> > How can DPBs securely evolve? > > Say, I now create a private XPTO provider and add a DPB with a specific > functionality using the next code. > > Then tomorrow Firebird devs adds this same code for a functionality > that's interpreted in y-valve.
May be clumplets for providers should be encapsulated into high-level clumplet - something like what we already have for network addresses? We add one code to mark such clumplet. Data in such clumplet starts with the name of target provider. Next block of provider parameters go. We will have to keep existing mix for traditional providers - engine and remote redirector, but for custom providers suggested method is better than just having a watermark for system/user parameters cause it works in a case when 2 non-standard providers are present at the same time. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
