Subject | Re: [Firebird-Architect] UDR Engine |
---|---|
Author | Vlad Khorsun |
Post date | 2008-06-25T08:17:18Z |
Alex Peshkov:
it user would specify *text* of programm module written on this LANGUAGE. And
this is database engine responsibility to use corresponding compiler (or
interpretator) to deal with this source code.
If we agreed with such interpretation then it is obvious that our approach (at
least currently implemented) is slightly different. So, we must not use LANGUAGE
clause or not use any real language (in LANGUAGE clause) for our binary plugins.
I think it is true even for current Java plugin - it operates not with Java
source code but with compiled byte-code.
Regards,
Vlad
> On Tuesday 24 June 2008 17:35, Adriano dos Santos Fernandes wrote:As i understand LANGUAGE clause was introduced with following in mind - after
>> Alex Peshkov escreveu:
>>> On Tuesday 24 June 2008 17:02, Adriano dos Santos Fernandes wrote:
>>>> <language CPP>
>>>> plugin_module UDR_engine
>>>> </language>
>>>>
>>>> <language DELPHI>
>>>> plugin_module UDR_engine
>>>> </language>
>>> Adriano, when I see a need to specify in config file what compiler was
>>> used to create binaries, I stop to understand anything. What if someone
>>> wants to write plugin using bcc32 - borland C compiler? Should it be
>>> Delphi or C++? What to do if assembler is used? Or fortran-77?
>>> This is compiled binary, no need to add any more language information.
>> I do have only two alternatives:
>> 1) Call "NATIVE" or "BINARY", the language implemented by this plugin
>> 2) Change LANGUAGE DDL clause to PLUGIN - it doesn't invalidated the
>> proposed UDR plugin
>
> Thank you, understood - this is in order to provide language information to
> DDL level. But may be it's really better to call it BINARY?
it user would specify *text* of programm module written on this LANGUAGE. And
this is database engine responsibility to use corresponding compiler (or
interpretator) to deal with this source code.
If we agreed with such interpretation then it is obvious that our approach (at
least currently implemented) is slightly different. So, we must not use LANGUAGE
clause or not use any real language (in LANGUAGE clause) for our binary plugins.
I think it is true even for current Java plugin - it operates not with Java
source code but with compiled byte-code.
> In order not toI also against duplicate entries in config.
> confuse people. Certainly, everyone who wants can add any entries to his
> config file. But in default configuration I prefer not to have confusing
> entries - they may become a source of multiple questions in support :)
Regards,
Vlad