Why not just establish a mechanism for other providers to register their
dpb codes. It isn't like their is either a shortage of unused codes or a
large number of new providers. That would also provide an opportunity to
discuss and possibly improve a proposal.
I can't help but think that people are trying to make a major problem out
of something that is completely trivial.
On Monday, March 30, 2015, Alex Peshkoff <peshk...@mail.ru> wrote:
> 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
>
--
Jim Starkey
------------------------------------------------------------------------------
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
