From: Adriano d. S. F. <adr...@uo...> - 2008-02-28 10:53:01
|
Alex Peshkov escreveu: > On Wednesday 27 February 2008 15:29, Adriano dos Santos Fernandes wrote: > >> Adriano dos Santos Fernandes escreveu: >> >>> * Not the dumb concept of Vulcan provider requiring another C interface, >>> but the official API going direct to the engine. I'm not sure if you're >>> understand me, but for me is clear that the same API available to >>> clients should be available to external modules (engines) and there is >>> no reason for engine providers entry-points be different than y-valve >>> entry-points. >>> >> To make things more clear: having a unified API (now ISC/GDS) we can >> encapsulate this API in C++ classes and use it in our utilities and in >> internal dynamic queries. Once we establish these classes as a public >> API it will be direct usable for users in external engines and the client. >> > > With new public API we may define that handles are pointers, and forget this > part of problem. Current converter from 32 bit handles will remain to support > legacy ISC API, and that legacy ISC API suuport library can be designed to be > able to talk to any library (yValve, engine, remote). Problem is that we can't wait for it (or forever) to have external engines. Don't we have some priorities: SMP, WAL, read-ahead and want go step by step? :-) Agree on a complete public API will take time, implement legacy support over it too. Adriano |