Re: [Firebird-devel] ODP: Increasing CHAR/VARCHAR max. length to 64KB
On 24/05/2021 07:27, Mark Rotteveel wrote: > On 24-05-2021 00:11, Adriano dos Santos Fernandes wrote: >> It's also funny that the few who direct uses the old API and do not want >> to migrate and asks for core team to maintain it, generally are the ones >> constantly asking for new features and fast releases. > > Is this some thinly veiled jab at me? > No, it's not for anyone directly, I'm just saying some people wants everything. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Increasing CHAR/VARCHAR max. length to 64KB
On 24-05-2021 00:11, Adriano dos Santos Fernandes wrote: It's also funny that the few who direct uses the old API and do not want to migrate and asks for core team to maintain it, generally are the ones constantly asking for new features and fast releases. Is this some thinly veiled jab at me? Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Increasing CHAR/VARCHAR max. length to 64KB
On 22/05/2021 07:20, Mark Rotteveel wrote: > On 22-05-2021 12:03, Dimitry Sibiryakov wrote: >> 22.05.2021 11:10, Karol Bieniaszewski wrote: >>> And the final conclusion why new API is better then old one as it was >>> accepted and preffered. >> >> For application development new API isn't better than old one. Its >> aim is Firebird plugins development where it has advantage of a single >> entry point. > > That doesn't match the intent expressed elsewhere in this thread to > introduce features/types that are only accessible through the new API. > It seems people change what has been said. I've proposed *to support* the new feature in the legacy API. And more, in a way it would be very easy to use it, nothing needing a difficult adaptation to a new version with many things changed together when incrementing a version (that was never been incremented before). What I did say I didn't support is to create new-old-API, which things it already have in a different way it have now. And actually to be *used directly*, by non C++ code, both APIs are not easy to use. It's the same with Win32 API, COM API and everything else. It could have an utility layer on top of it, but I don't think it will be better than language focused APIs on top of the current new API. I have been developing (not public) one for C++, supporting tuples, strings, etc, that for C++ it makes the usage very easy. And it's what others languages already have too (also on top of old API). It also must be clear that we're talking about new Firebird features and the old API is in the way of them, as well not supporting the features and engineering changes done since v3. It's not in the way because there is a new API, but because that old API was not good (non extensible, for example). So when we talk about fix/reorganize old-API or introduce all new behavior in it (even when difficult) because people can not (do not want to) migrate, we are surely throwing away many efforts and doing things wrongly. It's also funny that the few who direct uses the old API and do not want to migrate and asks for core team to maintain it, generally are the ones constantly asking for new features and fast releases. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Increasing CHAR/VARCHAR max. length to 64KB
On 22-05-2021 12:03, Dimitry Sibiryakov wrote: 22.05.2021 11:10, Karol Bieniaszewski wrote: And the final conclusion why new API is better then old one as it was accepted and preffered. For application development new API isn't better than old one. Its aim is Firebird plugins development where it has advantage of a single entry point. That doesn't match the intent expressed elsewhere in this thread to introduce features/types that are only accessible through the new API. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ODP: Increasing CHAR/VARCHAR max. length to 64KB
22.05.2021 11:10, Karol Bieniaszewski wrote: Isn’t such documentation already available by the new API developers? No. Its benefits, comparision with simplicity about use, speed, memory usage, extenibility.. Nothing like this. And the final conclusion why new API is better then old one as it was accepted and preffered. For application development new API isn't better than old one. Its aim is Firebird plugins development where it has advantage of a single entry point. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] ODP: Increasing CHAR/VARCHAR max. length to 64KB
Isn’t such documentation already available by the new API developers? I cannot imagine to have not comparision between every code in old vs new api. Its benefits, comparision with simplicity about use, speed, memory usage, extenibility.. And the final conclusion why new API is better then old one as it was accepted and preffered. It only require some rework for publicity or simply show it as draft and then extend/correct. regards, Karol Bieniaszewski Od: Mark Rotteveel Wysłano: sobota, 22 maja 2021 09:39 Temat: Re: [Firebird-devel] Increasing CHAR/VARCHAR max. length to 64KB On 22-05-2021 09:19, Dmitry Yemanov wrote: > 22.05.2021 10:06, Mark Rotteveel wrote: > >> The majority of our users probably still use the old API, either >> directly or indirectly. Given the undocumented state of the new API, I >> suspect it does not see a lot of usage, nor will it unless that changes. >> >> Introducing features that only benefit users of the new API, which - >> to be a bit hyperbolic - primarily seem to be the Firebird core >> developers themselves, seems a bit off to me. >> >> What is the point of this, and what is the benefit to our users? > > This sounds similar to the Dialect 1 problem. If all the new features > are also available in the old API, what's the point for users to migrate > to the new one? (even if we'd have an API guide published). I acknowledge that it is a bit of chicken-and-egg problem, but I think first more work needs to be done to actually **document** the new API, with basic examples to demonstrate it. If users don't know where to start or how to use it, then even new shiny features probably won't motivate enough to switch. And lets not forget the increased risk that having to invest to switch anyway, people might consider switching to an entirely different DBMS), which I think is bigger than with dialect 1 vs 3. Mark -- Mark Rotteveel 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
