It has been pointed out that the client and plugin APIs are used by different types of developers for different purposes. You didn't respond, so it's hard to know whether you disagreed, didn't understand the point, or just didn't care.
There is no benefit to forcing two completely different interfaces into one. If you are still reading, do you have anything to add to the idea of using COM as the plugin interface? I elaborated on that recently. You didn't respond, so it's hard to know whether you disagreed, didn't understand, or just didn't care. To save you the trouble of looking up the post, a COM object can support any number of interfaces each of which is immutable. This means that every type of plugin can have a distinctive and use-appropriate interface. And, if requirements change, additional interfaces can be added for full forward and backward compatability. COM, incidentally, in implemented in the object itself and requires no runtime. > On Aug 10, 2014, at 12:50 PM, Adriano dos Santos Fernandes > <adrian...@gmail.com> wrote: > >> On 10-08-2014 12:45, Dimitry Sibiryakov wrote: >> 10.08.2014 17:41, Adriano dos Santos Fernandes wrote: >>> And none of this are passed from your library to Firebird, i.e., >>> plugins, external routines. >> >> When will you start to separate application API and plugin API?.. > > I do not see any sane reason to create two flavor of APIs for a thing > which must be integrated. > > > Adriano > > ------------------------------------------------------------------------------ > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
