[Firebird-devel] New Interface
Hi! Some note from an outsider view. #1 : both client plugin API MUST support C-tyle API (lowest common dominator) - standard data types, zero terminated strings, pointers/handles, records, stdcall/cdecl functions, NO objects/interfaces - most of the API developers will and can only use this. (if will be not supported most of the user base will be lost) #2 : old client API should not be changed at all - why the new API if old one is also developed? - backward compatibility #3 : client plugin OO API - only C++ developers can use is (small part of the whole user base pie) - not just the different Object memory layout is the problem, but the different memory managers also. Object can be shared via API just in case of same compiler with same memory optimization settings AND shared memory manager. - why maintain a second one API? Can gain siginficant performance over C style API? What are the cons? #4 : new API should be designed from scratch, in mind of : - eliminate/expand current limits - better multithread scalability - make place for future FB developements - make place for supporting missing SQL standard features -- Molnár Attila szoftverfejlesztő Tel : 372- E-mail: amol...@mve.hu LIBRA Szoftver zrt. 1113 Bp. Karolina út 65. Tel: 372- Fax: 209-1477 Web: www.mve.hu E-mail: i...@mve.hu Olvasson ügyfeleinkkel elért közös sikereinkről: http://www.mve.hu/hu/referenciaink -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 9:12, Molnár Attila wrote: #3 : client plugin OO API - only C++ developers can use is (small part of the whole user base pie) It is not true. Common Object Model is supported not only in C++ compilers. Current problem is the result of two factors: 1) Our object hierarchy is not compatible with IUnknown that kick Delphi out of game. 2) Those who wrote FPC interface module didn't use CORBA-style interfaces. - not just the different Object memory layout is the problem, but the different memory managers also. Object can be shared via API just in case of _*same compiler with same memory optimization settings AND shared memory manager*_. It is not true as well. Memory manager is not a problem as long as object are freed in the same module where were created. Reference counting solves this well. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] So, What's wrong with IBPP?
Firebird already has a C++ Interface that is widely if not universally used by C++ Developers (including myself) to access the Firebird API. This is IBPP. IMHO, it is well designed, stable and fit for purpose. It compares well with similar libraries such as MySQL++ and Oracle OCCI. On the other hand, the FIrebird project has developed a second and incompatible C++ interface as part of FB3. This has to be an implicit criticism of IBPP and the new interface would be expected to be a big improvement on IBPP, if existing C++ applications are to be migrated to the new interface or for new applications to choose it over IBPP. It clearly must have a wow factor if it is to take Firebird boldly into the future. However, when I compare IBPP with the FB3 interface, a different picture emerges. Database attachment and transaction management are broadly similar (so nothing here to get you excited), but there is a big difference in data handling. IBPP (as do MySQL++ and Oracle OCCI) handles all the messy details of accessing column data and setting input parameters. It allows you to access each column by position or name and handles type conversion for you. This is where the real value added nature of IBPP comes in. C++ is more than just being Object Orientated: it is about being able to express the algorithm in a natural fashion without having to get down amongst the bits. IBPP allows you to do this. In comparison, the new FB3 API appears to deliver each row into an untyped (unsigned char*) buffer, which the user then has to parse using a separately provided metadata structure. When faced with a choice between IBPP and the new FB3 interface, I can't see why any C++ Programmer would choose an interface that meant poking around in a buffer, when an interface was available that provided type safe access to column data. So what is the point of this new interface? It is certainly not there to improve the Firebird experience for Delphi/Pascal, 'C' or PHP clients. It will not replace IBPP. I suppose IBPP may be rewritten to use the new interface itself - although the motivation to do is unlikely to be very strong and will, in any case, not make any difference to the IBPP user. If IBPP is not rewritten to use it then who will? I can't see the justification for the new interface. It does not improve on IBPP and will not make Firebird more acceptable to the C++ community while, at the same time, it will lessen the attractiveness of Firebird to just about everyone else. A uniquely pointless exercise. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] COM for Plugins
On 08/09/14 01:30, Jim Starkey wrote: Isn't COM a natural technology for plugins? Load a module, lookup the query interface interface, then probe for known interfaces. If one is found, it identifies both the formal interface and, by implication, the type of plugin. By definition, COM interfaces are immutable, so there is not question of forward or backward compatibility. On the other hand, a COM object can support number of interfaces, so extensions can be implemented as new interfaces leaving older interfaces active for backwards compatibility. And since a COM interface just happens to be a C++ class, COM object/plugins are almost trivial to code. This eliminates all sorts of version numbering issues, problems with calling methods that don't actually exist, etc. And, of course, it completely eliminates any need for a roll-your-own erzatz vtable. COM, incidentally, was not invented by Microsoft but by Apollo computer (which, incidentally, bootstraped Interbase) and was a adopted by the consortium that eventually launched the Open Software Foundation (OSF-1 anyone?). I don't think COM is even a candidate for a client API, but it is a great choice for plugins. COM was a first candidate when making a choice. We decided not to use it for at least 3 reasons. Immutable interfaces are probably very good when need to change them happens not too often. But something makes me think that not too big experience with planning new interfaces will cause changes in them very soon. With immutable model code will get very dirty with all this checks of a type of interface in this particular plugin. Upgrading version of interface causes some pain when interface is received first time, but later we may call missing version and get 'normal' not implemented error. Next, COM means UTF16 (at least on windows). Do we want to change our favorite UTF8 to UTF16 on every call? We decided that we do not. And last issue. IUnknown alone is far not a full COM, at least automation is needed. I do not know an easy way to have automation tables on non-windows platforms. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 08/08/14 20:40, Jim Starkey wrote: On Aug 8, 2014, at 9:05 AM, Adriano dos Santos Fernandes adrian...@gmail.com wrote: On 08/08/2014 08:52, Jim Starkey wrote: So, if I understand your original goals, again as an outsider, I would have to say that your current interface proposal does not meet them. Each step in the progression may have seen logical, but the end result is not. I'm resisting to reply to you and Dimitry S., but I actually think what you're saying is abstract bullshit. You actually seem to not even looked at the current code, interfaces or proposed changes. You're telling nothing new nor useful here. Adriano, calling something abstract bullshit is not a particularly compelling technical argument. If you want to add something constructive to the discussion, why don't you tackle my points one by one? The code is irrelevant; the interface has to live forever. You are promoting an interface that is not efficient, incompatible with all existing applications, is alien to standard industry usage, doesn't advance the state of the art, don't follow accepted industry standards, and will not attract new developers to Firebird. It is, from all appearances, something the crawled out of the primordial ooze of a really bad idea that the client API should be the same as the plugin API. Technical issues can, in fact, be discussed with more depth than +1. In fact, everything in engineering is a tradeoff, and tradeoffs can be reasonably balanced and discussed. But dismissing something that you don't agree with as abstract bullshit is never warranted. Yes, Adriano, your style is OK for a pub, but not for a tech list. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] COM for Plugins
11.08.2014 10:38, Alex Peshkoff wrote: Next, COM means UTF16 (at least on windows). Do we want to change our favorite UTF8 to UTF16 on every call? We decided that we do not. And last issue. IUnknown alone is far not a full COM, at least automation is needed. I do not know an easy way to have automation tables on non-windows platforms. You are mixing up COM and OLE. They are different things. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
Lets see the next scenatios #1 : API call creates object and returned to host - in this case object has to be readonly (at least buffer like fields)1 - host has to support reference counting2 #2 : API call parameterised by a host created object - see #1 1 : can't write because in that case data contained by the object could be allocated by different memory managers 2 : Must have all mayor language/compilers support ref.count and has to be the same With this restrictions what gain do you have with OO/Interface API over C style API? On 2014.08.11. 10:02, Dimitry Sibiryakov wrote: It is not true as well. Memory manager is not a problem as long as object are freed in the same module where were created. Reference counting solves this well. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
BTW API and host has different (can't have) class information (class pointer, VMT, etc..) for the same object, so by definition they not communicate with the SAME class. The classes could have same name, and can act the same, but the equality operation would give you FALSE result. Also inheritance handling definiatily would be problem (different VMT, and different memory mapping at the two sides, etc...). So basicly pure Object based API is off the table. Interface based might be good, and we ended up with COM. On 2014.08.11. 10:49, Molnár Attila wrote: Lets see the next scenatios #1 : API call creates object and returned to host - in this case object has to be readonly (at least buffer like fields)1 - host has to support reference counting2 #2 : API call parameterised by a host created object - see #1 1 : can't write because in that case data contained by the object could be allocated by different memory managers 2 : Must have all mayor language/compilers support ref.count and has to be the same With this restrictions what gain do you have with OO/Interface API over C style API? On 2014.08.11. 10:02, Dimitry Sibiryakov wrote: It is not true as well. Memory manager is not a problem as long as object are freed in the same module where were created. Reference counting solves this well. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 10:49, Molnár Attila wrote: #1 : API call creates object and returned to host - in this case object has to be readonly (at least buffer like fields)^1 - host has to support reference counting^2 #2 : API call parameterised by a host created object - see #1 1 : can't write because in that case data contained by the object could be allocated by different memory managers Transferring data by value for integer types and copying data from strings to internal buffers is enough. 2 : Must have all mayor language/compilers support ref.count and has to be the same Reference counting is just a matter of calling obj-addRef and obj-Release. Every language that can call object's method is ok. Some languages (like Delphi) do it automagically when interface variable is dying, in others you have to call these methods by hand. That's all. With this restrictions what gain do you have with OO/Interface API over C style API? Remember, that new API wasn't designed as a public API. It was supposed to be a new interface between Y-valve and providers, nothing more. ISC API in this place would add too much overhead or require significant changes in engine code. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 10:59, Molnár Attila wrote: So basicly pure Object based API is off the table. Interface based might be good, and we ended up with COM. Funny that you said that. Following article makes clear that they are exactly the same: http://www.codeproject.com/Articles/338268/COM-in-C -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
Den 2014-08-10 12:04 skrev Dmitry Yemanov såhär: 10.08.2014 13:55, Reinier Olislagers wrote: However, apparently FB devs don't think it's important to keep it in sync with the C++ interface - even if third parties could submit patches for that. So in effect, new FB (features) will not be compatible with any language that does not have C++ support. So far we're trying to find a compromise. I've been following this thread with interest. Being an end user (not API user) i don't really understand all the details, but it appears to me as if Adriano et al are arguing in favour of a C++ API and some hacks to make that API accessible from non C++ compatible languages. While I very much like the idea of an OO interface generally speaking, it seems to me that the FB project would have to take on a huge amount of work to make that API accessible from any language. The proposed solutions seem very hacky to me - too low-level and dependent on details of various compiler implementations, that might also change between compiler versions. Just to keep it accessible from Delphi as well as FP seems like excessive work, especially considering that the details of vtable etc might change in new version of FP and Delphi. My question in that context is what is really the point of having a C++ API rather than a regula C one, which appears to have much less of those compatibility problems? If the point is small, it seems not worth the trouble. Regards, Kjell -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4514) Allow Firebird Service to be started as automatically (delayed) in Windows (starting at Vista)
Allow Firebird Service to be started as automatically (delayed) in Windows (starting at Vista) -- Key: CORE-4514 URL: http://tracker.firebirdsql.org/browse/CORE-4514 Project: Firebird Core Issue Type: Improvement Components: Guardian Environment: Windows 8, VS2012 Reporter: André Ziegler Priority: Trivial Since Vista, services can be set as automatically delayed for the start type (http://msdn.microsoft.com/en-us/library/windows/desktop/ms685155%28v=vs.85%29.aspx). It would be nice if the Control Panel Applet could allow us to start the service delayed because on a developer machine you don't need the service directly at boot. So it can be started with a delay to improve boot performance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
So this Interface is not designed and made for clinet component developers and communicatin with server but just for Firebird engine inside use? In that case just do what you want. ;) On 2014.08.11. 11:05, Dimitry Sibiryakov wrote: Remember, that new API wasn't designed as a public API. It was supposed to be a new interface between Y-valve and providers, nothing more. ISC API in this place would add too much overhead or require significant changes in engine code. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] So, What's wrong with IBPP?
On Mon, 11 Aug 2014 09:18:58 +0100, Tony Whyman tony.why...@mccallumwhyman.com wrote: Firebird already has a C++ Interface that is widely if not universally used by C++ Developers (including myself) to access the Firebird API. This is IBPP. IMHO, it is well designed, stable and fit for purpose. It compares well with similar libraries such as MySQL++ and Oracle OCCI. ... I can't see the justification for the new interface. It does not improve on IBPP and will not make Firebird more acceptable to the C++ community while, at the same time, it will lessen the attractiveness of Firebird to just about everyone else. A uniquely pointless exercise. I think this discussion is getting a bit out of control. I for one still have tens of unread messages on this subject, but I get the feeling people are talking past each other instead of with each other. I think we **first** need to establish the use case(s) for the API(s), and the target audience of the interface(s), then we should establish the needs for these use cases and audiences and only then should we discuss implementation options. I believe I have seen the following use cases: * Connecting/querying Firebird * Plugin development * Provider development And target audience: * Firebird developers * Driver developers * Plugin/provider developers(?) * Application developers To illustrate: you seem (?) to be speaking from the perspective of a target audience who use the interface in application development, and where you don't want to deal with all the nitty gritty low-level details, here IBPP is probably a good fit (but as I haven't used it, I can't say). However speaking as the developer of Jaybird, I don't want an API that will perform too many conversions or work that I will need to redo to make it work the same or similar as the wire protocol implementation, and to make it work within the rules established by JDBC. In that case an API that does too much heavy lifting is actually a hindrance (or at minimum a potential performance bottleneck). These are already two - somewhat - conflicting needs. Personally I'd say that Firebird should at minimum have a low-level API (which the current ibase.h provides, although it has some annoyances). A higher level API (like IBPP) to do some of the heavy lifting for application development is a nice to have. And as you say: it already exists: IBPP. For the rest of the discussion: I think we need to take a step back and do a proper analysis. Mark -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] So, What's wrong with IBPP?
Mark, I expressed concern last week that there was too much heat on the list and got told that passion was good - you can't win :( You said Personally I'd say that Firebird should at minimum have a low-level API (which the current ibase.h provides, although it has some annoyances). In a nutshell, this seems to be where the argument lies. If the developers agreed that the existing low level API would continue to be maintained and to support new functionality then most of us would move on and get on with our lives, and if the Firebird developers want to develop a second C++ API - then that's their problem. Unfortunately, the response seems to be that everyone should move to the new C++ API and if your preferred programming language can't support it - well that's your problem. There needs to be a compromise - but at the moment it seems hard to see a middle way. On 11/08/14 10:45, Mark Rotteveel wrote: On Mon, 11 Aug 2014 09:18:58 +0100, Tony Whyman tony.why...@mccallumwhyman.com wrote: I think this discussion is getting a bit out of control. I for one still have tens of unread messages on this subject, but I get the feeling people are talking past each other instead of with each other. I think we **first** need to establish the use case(s) for the API(s), and the target audience of the interface(s), then we should establish the needs for these use cases and audiences and only then should we discuss implementation options. I believe I have seen the following use cases: * Connecting/querying Firebird * Plugin development * Provider development And target audience: * Firebird developers * Driver developers * Plugin/provider developers(?) * Application developers To illustrate: you seem (?) to be speaking from the perspective of a target audience who use the interface in application development, and where you don't want to deal with all the nitty gritty low-level details, here IBPP is probably a good fit (but as I haven't used it, I can't say). However speaking as the developer of Jaybird, I don't want an API that will perform too many conversions or work that I will need to redo to make it work the same or similar as the wire protocol implementation, and to make it work within the rules established by JDBC. In that case an API that does too much heavy lifting is actually a hindrance (or at minimum a potential performance bottleneck). These are already two - somewhat - conflicting needs. Personally I'd say that Firebird should at minimum have a low-level API (which the current ibase.h provides, although it has some annoyances). A higher level API (like IBPP) to do some of the heavy lifting for application development is a nice to have. And as you say: it already exists: IBPP. For the rest of the discussion: I think we need to take a step back and do a proper analysis. Mark -- 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
Re: [Firebird-devel] So, What's wrong with IBPP?
On Mon, 11 Aug 2014 11:14:28 +0100, Tony Whyman tony.why...@mccallumwhyman.com wrote: Mark, I expressed concern last week that there was too much heat on the list and got told that passion was good - you can't win :( Passion is good, until it becomes an obstacle. You said Personally I'd say that Firebird should at minimum have a low-level API (which the current ibase.h provides, although it has some annoyances). In a nutshell, this seems to be where the argument lies. If the developers agreed that the existing low level API would continue to be maintained and to support new functionality then most of us would move on and get on with our lives, and if the Firebird developers want to develop a second C++ API - then that's their problem. Extending the current API of ibase.h has its own challenges (eg assumption of 16 bit string length), and annoyances like confusing parameters (types, meaning) and parameter order. Last week I used a generator to generate a JNA interface (a way of calling native libraries from Java without writing C or C++ code yourself) and that generator got pretty confused because the Firebird API doesn't follow some of the conventions assumed by that generator. I had to fix some of this by hand. A replacement API might be better (although I admit that has its own challenges and costs). Unfortunately, the response seems to be that everyone should move to the new C++ API and if your preferred programming language can't support it - well that's your problem. There needs to be a compromise - but at the moment it seems hard to see a middle way. Agreed. Mark -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 05:43, Alex Peshkoff wrote: Technical issues can, in fact, be discussed with more depth than +1. In fact, everything in engineering is a tradeoff, and tradeoffs can be reasonably balanced and discussed. But dismissing something that you don't agree with as abstract bullshit is never warranted. Yes, Adriano, your style is OK for a pub, but not for a tech list. What is appropriate for a tech list is people who never looks on code, right? Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 06:04, Kjell Rilbe wrote: Den 2014-08-10 12:04 skrev Dmitry Yemanov såhär: 10.08.2014 13:55, Reinier Olislagers wrote: However, apparently FB devs don't think it's important to keep it in sync with the C++ interface - even if third parties could submit patches for that. So in effect, new FB (features) will not be compatible with any language that does not have C++ support. So far we're trying to find a compromise. I've been following this thread with interest. Being an end user (not API user) i don't really understand all the details, but it appears to me as if Adriano et al are arguing in favour of a C++ API and some hacks to make that API accessible from non C++ compatible languages. While I very much like the idea of an OO interface generally speaking, it seems to me that the FB project would have to take on a huge amount of work to make that API accessible from any language. The proposed solutions seem very hacky to me - too low-level and dependent on details of various compiler implementations, that might also change between compiler versions. The hack approach dependent on compilers details is the one we use currently. It's exactly what I tried to avoid, writing a stable and compiler independent layout. Just to keep it accessible from Delphi as well as FP seems like excessive work, especially considering that the details of vtable etc might change in new version of FP and Delphi. If they're really the dumb people wanting to kill their languages, they will change. My question in that context is what is really the point of having a C++ API rather than a regula C one, which appears to have much less of those compatibility problems? If the point is small, it seems not worth the trouble. My API is a C API with good access to C++, Delphi and FPC, until nobody pointed the contrary. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 06:25, Molnár Attila wrote: So this Interface is not designed and made for clinet component developers and communicatin with server but just for Firebird engine inside use? In that case just do what you want. ;) He's totally wrong on this! Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
53e74645.6000...@ibphoenix.com Message-ID: a2df4a7f7c30f812d5f98c4057c3a...@imap.procolix.com X-Sender: m...@lawinegevaar.nl User-Agent: RoundCube Webmail/0.2 On Sun, 10 Aug 2014 12:15:33 +0200, Dimitry Sibiryakov s...@ibphoenix.com wrote: was a lot of languages (including Java and .NET in their early days) that were unable to use good old C interface. They had to invent tricks (JNI for for example or using network protocol directly) to get access to Firebird, not you to provide a interface to them. Nothing has changed. IIRC, calling C interfaces from Java code (using JNI), has been possible from Java 1 (or maybe 1.1), but most Java developers don't want to deal with native dependencies in their applications. That in itself is the main reason to write against a wire protocol and not against a native library. The main reason that Jaybird actually supports a native library at all is for Firebird embedded. Mark -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 12:47, Adriano dos Santos Fernandes wrote: The hack approach dependent on compilers details is the one we use currently. Currently used pure abstract classes are exactly like in COM. And The Component Object Model specifies a *programming-language-independent _binary standard_ for object implementations* (i.e., it specifies what the implementation of the objects has to look like). Any object conforming to this standard is a legitimate Windows Object, no matter what language is used to implement it. http://www.objs.com/x3h7/ole2.htm To make current interface completely compatible with MS COM (Delphi/FPC IInterface) it is enough to add a single method - QueryInterface. All this was already discussed years ago. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] So, What's wrong with IBPP?
11.08.2014 13:45, Mark Rotteveel wrote: To illustrate: you seem (?) to be speaking from the perspective of a target audience who use the interface in application development, and where you don't want to deal with all the nitty gritty low-level details, here IBPP is probably a good fit (but as I haven't used it, I can't say). However speaking as the developer of Jaybird, I don't want an API that will perform too many conversions or work that I will need to redo to make it work the same or similar as the wire protocol implementation, and to make it work within the rules established by JDBC. In that case an API that does too much heavy lifting is actually a hindrance (or at minimum a potential performance bottleneck). These are already two - somewhat - conflicting needs. Personally I'd say that Firebird should at minimum have a low-level API (which the current ibase.h provides, although it has some annoyances). A higher level API (like IBPP) to do some of the heavy lifting for application development is a nice to have. And as you say: it already exists: IBPP. This is exactly the developer's position, at least how I understand it myself ;-) IBPP is C++ only and too high-level. The FB API should be lower-level and language-independent. The legacy ISC API mostly serves this goal (although it's not that low-level really, some hidden conversions/movements happen there), but it's showing its age. So we attempted to offer a modern replacement with the v3 OO API. IBPP can still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would act the same for Delphi, etc. They just need to be ported to the new core API (whatever it will be). Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
Adriano, this is a completely inappropriate response. If you think he is wrong, you must explain exactly why he is wrong. While reasoning carries weight, person opinions do not. So, if you think he is wrong, olease elaborate. On Aug 11, 2014, at 7:48 AM, Adriano dos Santos Fernandes adrian...@gmail.com wrote: On 11/08/2014 06:25, Molnár Attila wrote: So this Interface is not designed and made for clinet component developers and communicatin with server but just for Firebird engine inside use? In that case just do what you want. ;) He's totally wrong on this! 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
Re: [Firebird-devel] New Interface
On 08/11/14 14:52, Mark Rotteveel wrote: IIRC, calling C interfaces from Java code (using JNI), has been possible from Java 1 (or maybe 1.1), but most Java developers don't want to deal with native dependencies in their applications. That in itself is the main reason to write against a wire protocol and not against a native library. The main reason that Jaybird actually supports a native library at all is for Firebird embedded. And will it be possible to invoke client plugins for non-standard authentication / encryption? -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Handling isc_arg_interpreted in a statusvector
On 08/09/14 16:40, Mark Rotteveel wrote:
Currently jaybird is handling isc_arg_interpreted the same as
isc_arg_string and assumes it is a message parameter for the message of
the previous error code.
However I was just debugging the handling of the statusvector for the
new native client wrapper in Jaybird and I noticed - when trying to
connect to a non-existent database - that Firebird was returning a
statusvector with:
isc_arg_gds, isc_io_error (I/O error during {0} operation for file
{1}),
isc_arg_string, CreateFile (open),
isc_arg_string, (name of the database),
isc_arg_gds, isc_io_open_err (Error while trying to open file),
isc_arg_interpreted, The system cannot find the file specified.
isc_arg_end
As Jaybird was interpreting the last entry as a message parameter to
isc_io_open_err, and that doesn't have a parameter, it isn't showing
anything.
Should I handle isc_arg_interpreted as an element on its own?
isc_arg_interpreted is handled on its own - a string, just a string to
type. It's not a parameter of other message.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 15:36, Dimitry Sibiryakov wrote: 11.08.2014 13:39, Vlad Khorsun wrote: As you already 'discovered' absence of not needed QueryInterface in our classes, you should understand why it was not a mistake. It wasn't a mistake for Delphi only. It failed for FPC. I don't have FPC, and i never said i did something for it. I did translation to *Delphi* of part of new API by request of someone at UIB and that is all. There was an implicit assumption that what works for Delphi should work for FPC... Regards, Vlad -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 14:37, Alex Peshkoff wrote: hide reference counters under the hood as well as dealing with exceptions. Both not acceptable for us Why? Do you insist on manual calling of Release by cruelty only or you have some technical reasons? Will it be OK to return E_NOINTERFACE to FPC's loader of interface? There is no such things as interface loader. Interface is just a way to declare... err... interface. A passive thing. QueryInterface is called implicitly on typecasts. Returning of E_NOINTERFACE will cause typecast to fail. That's all. Somebody mentioned place for 3 pointers in the beginning of VT. What are the second and third? I posted links earlier: http://www.freepascal.org/docs-html/prog/progsu168.html#x212-2250008.2.13 http://www.freepascal.org/docs-html/prog/progsu167.html#x211-2240008.2.12 These are VMTs for classes and objects, not interfaces. Interfaces is a different beast: http://www.freepascal.org/docs-html/prog/progsu37.html#x44-430001.2.37 -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 09:45, Alex Peshkoff wrote: On 08/08/14 20:47, Adriano dos Santos Fernandes wrote: At least I have time to answer tech question. What a luck! Sure. Automatic vtable upgrade is ok for me, provided we have a trust-able and reliable way to add them. Attached a demo for it, search for upgrade. I implemented dummy PluginModule for the demo. It works provided that who called the method that returned the new object was compiled together (or with the same API version) of who is calling the object method. In most of cases I'd imagine, this is true. What do you think? Currently I do not know other usages. Some small detail - it's better to upgrade to the current version at once to avoid upgrading first to 4, next to 5, etc. Sure. But there may be more cases, like passing a [in]/out parameter, but may be possible in C++. May you be a bit more explicit here? If it's about passing interface as parameter - yes, version check/upgrade is needed here. But I do not catch how you differ for interface is it in or out? With pointers to pointers. Imagine something like this: void execute(/* in-out */ ITransaction** transaction); ITransaction* transaction = ...; execute(transaction); AFAIK we currently does not have this, however. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Handling isc_arg_interpreted in a statusvector
On Mon, 11 Aug 2014 16:48:48 +0400, Alex Peshkoff peshk...@mail.ru
wrote:
On 08/09/14 16:40, Mark Rotteveel wrote:
Currently jaybird is handling isc_arg_interpreted the same as
isc_arg_string and assumes it is a message parameter for the message of
the previous error code.
However I was just debugging the handling of the statusvector for the
new native client wrapper in Jaybird and I noticed - when trying to
connect to a non-existent database - that Firebird was returning a
statusvector with:
isc_arg_gds, isc_io_error (I/O error during {0} operation for file
{1}),
isc_arg_string, CreateFile (open),
isc_arg_string, (name of the database),
isc_arg_gds, isc_io_open_err (Error while trying to open file),
isc_arg_interpreted, The system cannot find the file specified.
isc_arg_end
As Jaybird was interpreting the last entry as a message parameter to
isc_io_open_err, and that doesn't have a parameter, it isn't showing
anything.
Should I handle isc_arg_interpreted as an element on its own?
isc_arg_interpreted is handled on its own - a string, just a string to
type. It's not a parameter of other message.
Thanks. For now I have handled it by printing additional parameters if
there are more parameters than placeholders (which solves this problem, and
cases were I potentially use an older message format with less parameters
than provided by Firebird). I will see if I need to create a more formally
correct solution by treating isc_arg_interpreted as a separate element.
Mark
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
53e8afd3.3010...@mail.ru Message-ID: 37c270dc067e4e9904bdcf9108c6f...@imap.procolix.com X-Sender: m...@lawinegevaar.nl User-Agent: RoundCube Webmail/0.2 On Mon, 11 Aug 2014 15:58:11 +0400, Alex Peshkoff peshk...@mail.ru wrote: On 08/11/14 14:52, Mark Rotteveel wrote: IIRC, calling C interfaces from Java code (using JNI), has been possible from Java 1 (or maybe 1.1), but most Java developers don't want to deal with native dependencies in their applications. That in itself is the main reason to write against a wire protocol and not against a native library. The main reason that Jaybird actually supports a native library at all is for Firebird embedded. And will it be possible to invoke client plugins for non-standard authentication / encryption? For now I have to answer that with a maybe. That is an area I will investigate for Jaybird 3.1 (or when more critical parts for Jaybird 3.0 are done). Mark -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4516) Crash running gstat or gbak after encryption is enabled
Crash running gstat or gbak after encryption is enabled --- Key: CORE-4516 URL: http://tracker.firebirdsql.org/browse/CORE-4516 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0 Alpha 2 Environment: Windows 7 Pro 64bits - FB 3.0 alpha 2 Reporter: Carlos H. Cantu if you run a gstat -a or a gbak -b in the database, right after enabling database encryption, it crashes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 08/11/14 16:57, Adriano dos Santos Fernandes wrote: But there may be more cases, like passing a [in]/out parameter, but may be possible in C++. May you be a bit more explicit here? If it's about passing interface as parameter - yes, version check/upgrade is needed here. But I do not catch how you differ for interface is it in or out? With pointers to pointers. Imagine something like this: void execute(/* in-out */ ITransaction** transaction); ITransaction* transaction = ...; execute(transaction); AFAIK we currently does not have this, however. A case with pointer to pointer is bad in many cases. Therefore (though it's not too good from first POV) I've used to return transaction from execute. IMHO we should better never such constructions. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
Since plugins pretty much need to be compiled with the same compiler as the engine, and since both COM objects and their clients will be compiled from the machine generated interface defintion headers, there is no danger of incompatibilities even if there are compilers incompatible with standard IDL compilers, which I seriously doubt. You are arguing that a 25 year old industry standard, widely adopted technology is unsafe but a crude, home-brew quasi-OO interface is not. I don't find your position convincing. Why don't you just say that you don't like COM because it wasn't invented here? The UTF-8 issue must be dealt with, certainly. I am in a part of the world without practical web access and will soon be out of even email. But when I get back to civilization and bandwidth, I will be happy to brush up on the latest. So far, the arguments I've heard against COM are mostly failures of understanding, not COM deficiencies. Oh, there is the argument that Firebird developers aren't good enough to handle immutable interfaces. That I reject out of hand. Hundreds of thousands of developers have learned to cope with stable interfaces. Probably more. On Aug 11, 2014, at 8:50 AM, Alex Peshkoff peshk...@mail.ru wrote: On 08/11/14 15:18, Jim Starkey wrote: Adriano, you are arguing that you are right and the rest of the world is wrong. COM is designed so any language can use it, but C++ can use either as explicit vectors of method pointer OR as a pure virtual interface. Either works, but using it as a C++ mechanism is very simple and powerful. Either works as long as vtable in C++ pure virtual interface has format exactly matching an explicit vector of method pointers. If some way can be proofed that it must always be so and another format of vtable is just a bug of compiler developers, I'll be glad to continue using c++ pure virtual interfaces (like it's done now). You may have noticed few defenders of your interface. Most have argued that it is ugly, hard to use, and very unlikely to meet its goals for mapping into native objects in multiple languages. That's bad argument. When Copernicus suggested his new model of the solar system everybody was against. With strong argument - we see ourself that it's Sun rotating around the Earth... These are legimate criticisms that you have not answered. Language on which suggested vtables are very easy to access should meet the following requirements: support pointers to functions, support structures (or in the worst case arrays) with reasonable members packing and support __cdecl calling convention. Certainly, far not all languages meet that requirements - but a lot of used in practice do. -- 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
Re: [Firebird-devel] New Interface
11.08.2014 18:18, Jim Starkey wrote: Since plugins pretty much need to be compiled with the same compiler as the engine Very questionable requirement. I can easily expect plugins written in Delphi. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 11:18, Jim Starkey wrote: Since plugins pretty much need to be compiled with the same compiler as the engine, Hum?? and since both COM objects and their clients will be compiled from the machine generated interface defintion headers, there is no danger of incompatibilities even if there are compilers incompatible with standard IDL compilers, which I seriously doubt. So, nobody should rely on undefined behavior, i.e., COM components must also manually generate vtables to be OK, specially if you're implementing non-Windows COM (something which does not exist). You are arguing that a 25 year old industry standard, widely adopted technology is unsafe but a crude, home-brew quasi-OO interface is not. I don't find your position convincing. Why don't you just say that you don't like COM because it wasn't invented here? The UTF-8 issue must be dealt with, certainly. I am in a part of the world without practical web access and will soon be out of even email. But when I get back to civilization and bandwidth, I will be happy to brush up on the latest. So far, the arguments I've heard against COM are mostly failures of understanding, not COM deficiencies. Oh, there is the argument that Firebird developers aren't good enough to handle immutable interfaces. That I reject out of hand. Hundreds of thousands of developers have learned to cope with stable interfaces. Probably more. COM is full of problems: - UTF16 - HRESULT with TLS access to errors - No real OOP, just object composing with QueryInterface - Ref. counting for all sorts of objects Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 17:47, Dmitry Yemanov wrote: 11.08.2014 18:18, Jim Starkey wrote: Since plugins pretty much need to be compiled with the same compiler as the engine Very questionable requirement. I can easily expect plugins written in Delphi. Agree. More, there is no reason to use same C++ compiler. Regards, Vlad -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 11:49, Adriano dos Santos Fernandes wrote: COM is full of problems: Also, the our-IDL compiler may generate COM (complex) wrapper code for our interfaces (simple). Doesn't this kill the argument to use something that does not really fit well as an internal API? Then if Delphi or .NET developers want to connect to the COM interfaces, they can, without sacrificing the C++ users (including the internal code). Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 16:49, Adriano dos Santos Fernandes wrote: COM is full of problems: - UTF16 - HRESULT with TLS access to errors Could you point out where COM specification is forcing usage of UTF16 and TLS for HRESULT? -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
Before this goes much further, can someone confirm that COM is compatible with Linux. I was always under the impression that it was a Windows only technology. Googling the subject does not come up anything other than DCOM and a lot of negative comments on COM. COM is full of problems: - UTF16 - HRESULT with TLS access to errors - No real OOP, just object composing with QueryInterface - Ref. counting for all sorts of objects 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
Re: [Firebird-devel] New Interface
This COM business has caught me off guard so let me be the first to admit that I don't know much about it. But if there's no Linux support for COM it would be dead on arrival as far as I would be concerned. (My contact looking to get out of Delphi is also looking for a way to dump Windows.) Despite it's rich heritage and seemingly elegant design, it seems that the only platforms actively supporting COM belong to Microsoft. Google can turn up information on COM but you have to know what you're looking for. That alone would indicate to me that caution should be exercised when barking up the COM tree. Nonetheless, this seems to indicate that interoperability is possible. http://msdn.microsoft.com/en-us/library/aa260790(v=vs.60).aspx On Aug 11, 2014, at 11:26 AM, Tony Whyman wrote: Before this goes much further, can someone confirm that COM is compatible with Linux. I was always under the impression that it was a Windows only technology. Googling the subject does not come up anything other than DCOM and a lot of negative comments on COM. COM is full of problems: - UTF16 - HRESULT with TLS access to errors - No real OOP, just object composing with QueryInterface - Ref. counting for all sorts of objects -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
It's been suggested to use Mozilla's XPCOM, which is similar to MSFT COM but cross platform and with multiple language bindings. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM I believe I saw some commentary about Mozilla being a bloated pig, which might weigh against considering xpcom, but I believe it's more of a specification than an implementation, so the bloated-ness may not be such an inherent part in this. Steve -- who has no direct experience with xpcom -Original Message- From: Tony Whyman [mailto:tony.why...@mccallumwhyman.com] Sent: Monday, August 11, 2014 8:26 AM To: firebird-devel@lists.sourceforge.net Subject: Re: [Firebird-devel] New Interface Before this goes much further, can someone confirm that COM is compatible with Linux. I was always under the impression that it was a Windows only technology. Googling the subject does not come up anything other than DCOM and a lot of negative comments on COM. COM is full of problems: - UTF16 - HRESULT with TLS access to errors - No real OOP, just object composing with QueryInterface - Ref. counting for all sorts of objects 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 -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 17:26, Tony Whyman wrote: Before this goes much further, can someone confirm that COM is compatible with Linux. I was always under the impression that it was a Windows only technology. Googling the subject does not come up anything other than DCOM and a lot of negative comments on COM. My googling leads to quite reasonable whitepaper: http://www.cs.umd.edu/~pugh/com/ Some quotes from there: Is provided on multiple platforms (Microsoft® Windows®, Windows 95, Windows NT�, Apple® Macintosh®, and many varieties of UNIX®) It is important to note that COM is a general architecture for component software. Although Microsoft is applying COM to address specific areas such as controls, compound documents, automation, data transfer, storage and naming, and others, any developer can take advantage of the structure and foundation that COM provides. For any given platform (hardware and operating system combination), COM defines a standard way to lay out virtual function tables (vtables) in memory, and a standard way to call functions through the vtables. Thus, any language that can call functions via pointers (C, C++, Smalltalk, Ada, and even BASIC) all can be used to write components that can interoperate with other components written to the same binary standard. IDL is only a tool for the convenience of the interface designer and is not central to COM's interoperability. It simply saves the developer from manually creating header files for each programming environment and from creating proxy and stub objects by hand. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On Aug 11, 2014, at 11:49 AM, Adriano dos Santos Fernandes adrian...@gmail.com wrote: COM is full of problems: - UTF16 - HRESULT with TLS access to errors - No real OOP, just object composing with QueryInterface - Ref. counting for all sorts of objects This what I mean by ignorance. COM was originally defined using 16 bit Unicode, not UTF-16. When it was defined, UTF-16 didn't exist. I don't know the status of UTF-8, but will look and report. COM defines a number of interfaces, the more important of which is queryInterface. User defined interfaces have no constraints on error handling other than that they should use exceptions, though this is something that can't be enforced. COM defined interfaces does specify error handling. HRESULT is just an artificial type. Look it up. I think you could handle it. Of course COM is an OO-technlogy. I don't know what you mean by not real OO, so I guess that is an Adriano-ism. COM is a language independent wrapper for objects with multiple interfaces. It says nothing about the implementation of the object. COM objects are reference counted. Reference counting is an near universal mechanism for controlling object lifetime in non-garbage collected systems. I presume you understand referencing counting, but perhaps you could your express your objections to it. We would get places faster if people would do their research before trying to shoot something down. It does suggest that they are more interested in winning than finding the best technical solution to a problem. Is COM the perfect solution to all problems? No, of course not. But it is very good solution for both structuring plugins and more delivering engine functionality to plugins in a stable, maintainable, efficient, and extensible manner. 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
Re: [Firebird-devel] New Interface
Another requirement not yet mentioned for C++ users, are exceptions. While we can easily just convert IStatus to Exception, if Exception is a FB class, not even derived from std::exception, it may be completely inappropriate for users applications. You know, each C++ project has its own requirements for exceptions. Firebird is one of them. In my demo (probably not need to send it, as nobody is doing concrete arguments against it, but still talking about others things), this can be personalized via police classes. AFAIR, this concept was created or consolidated by Andrei Alexandrescu for the Loki library, though that was a pure template library, not a library of interfaces. It consist more or less like this: typedef FbApiMyPolice MyFbApi; MyFbApi::IInterface* interface = ...; This happen to work very well, even in the first implementation in the prototype. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
Ok, I got it. I stand corrected. For the record, when I invented UDFs, neither C++ nor Delphi existed. Hell, C didn't even have function prototypes. On Aug 11, 2014, at 1:58 PM, Carlos H. Cantu lis...@warmboot.com.br wrote: DY Very questionable requirement. I can easily expect plugins written in DY Delphi. DY Dmitry ++1, as it already happens with UDFs (lots of them coded in Delphi). []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br DY 11.08.2014 18:18, Jim Starkey wrote: Since plugins pretty much need to be compiled with the same compiler as the engine -- 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
Re: [Firebird-devel] New Interface
11.08.2014 19:29, Adriano dos Santos Fernandes wrote: Another requirement not yet mentioned for C++ users, are exceptions. Worth reading before jumping in: http://tdm-gcc.tdragon.net/quirks https://gcc.gnu.org/wiki/WindowsGCCImprovements https://www.usenix.org/legacy/events/osdi2000/wiess2000/full_papers/dinechin/dinechin_html/ -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 14:51, Dimitry Sibiryakov wrote: 11.08.2014 19:29, Adriano dos Santos Fernandes wrote: Another requirement not yet mentioned for C++ users, are exceptions. Worth reading before jumping in: http://tdm-gcc.tdragon.net/quirks https://gcc.gnu.org/wiki/WindowsGCCImprovements https://www.usenix.org/legacy/events/osdi2000/wiess2000/full_papers/dinechin/dinechin_html/ What's your point? Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 19:55, Adriano dos Santos Fernandes wrote: What's your point? No exception is allowed to cross alien boundaries. Only modules built with the same compiler can throw and catch exceptions. Such modules has no problems you are talking about, so no hand-made unwind is needed. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 15:00, Dimitry Sibiryakov wrote: 11.08.2014 19:55, Adriano dos Santos Fernandes wrote: What's your point? No exception is allowed to cross alien boundaries. Only modules built with the same compiler can throw and catch exceptions. Such modules has no problems you are talking about, so no hand-made unwind is needed. No one is telling to pass exceptions across modules, it's quite the contrary. The generated impl. wrapper is going to guarantee that not happens in the Firebird code. But an (client) application wants to generate exception when accessing the API, and we do not know in advance what's the good classes for each project. Some may use like Firebird, an Exception not inherited, others wants std::exception, a Qt-based project would want another one... Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
Exceptions are clearly an issue. Exception handling is specific to the C++ runtime and can't be handled by other languages. This is specific to COM however, it applies to all cross language interfaces. A COM solution would be to have all methods return a COM object (null for success if no succes return is required), which could be either a proper result object or an error object. But it would require a queryInterface to determine which. There other ways to handle this, like separate call to fetch an error object if a non-object return indicated an error, etc. On Aug 11, 2014, at 2:29 PM, Adriano dos Santos Fernandes adrian...@gmail.com wrote: Another requirement not yet mentioned for C++ users, are exceptions. While we can easily just convert IStatus to Exception, if Exception is a FB class, not even derived from std::exception, it may be completely inappropriate for users applications. You know, each C++ project has its own requirements for exceptions. Firebird is one of them. In my demo (probably not need to send it, as nobody is doing concrete arguments against it, but still talking about others things), this can be personalized via police classes. AFAIR, this concept was created or consolidated by Andrei Alexandrescu for the Loki library, though that was a pure template library, not a library of interfaces. It consist more or less like this: typedef FbApiMyPolice MyFbApi; MyFbApi::IInterface* interface = ...; This happen to work very well, even in the first implementation in the prototype. 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
Re: [Firebird-devel] New Interface
On Aug 11, 2014, at 12:06 PM, Lester Caine wrote: On 11/08/14 12:53, Alex Peshkoff wrote: IBPP can still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would act the same for Delphi, etc. They just need to be ported to the new core API (whatever it will be). I agree with this is POV 100%. I've been following the debate on 'new interface' and to be honest I still don't understand where the problem is. Having used IBObjects on legacy projects, that has not been used for a long time as I am now reliant on PHP and Jaybird these days to pull results from Firebird. Neither of these need an internal interface weight down by C++ and I'm sure a lot of power users are in the same boat? C++ is a layer on top of the connection to the database and I'm sure if I need to revert to that I'd be looking to IBObjects again, but certainly windows will not be featuring in that which ever way I go. On Aug 11, 2014, at 2:08 PM, Adriano dos Santos Fernandes wrote: No one is telling to pass exceptions across modules, it's quite the contrary. The generated impl. wrapper is going to guarantee that not happens in the Firebird code. But an (client) application wants to generate exception when accessing the API, and we do not know in advance what's the good classes for each project. Some may use like Firebird, an Exception not inherited, others wants std::exception, a Qt-based project would want another one... I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL. There is never any case where I would want to see std:exception. Could it be time to start thinking about burying this idea that is looking more and more like a sacred cow? -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 20:20, Jim Starkey wrote: A COM solution would be to have all methods return a COM object (null for success if no succes return is required), which could be either a proper result object or an error object. But it would require a queryInterface to determine which. There other ways to handle this, like separate call to fetch an error object if a non-object return indicated an error, etc. Usual solution is returning HRESULT which may be a plain error code or a handle of error object that can be questioned later. Delphi/FPC have a special calling convention for this. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 15:29, Tom Coleman wrote: I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL. There is never any case where I would want to see std:exception. Could it be time to start thinking about burying this idea that is looking more and more like a sacred cow? Then the chances of not wanting a FbException (not inherited from std::exception) are also very high. This is what polices are for. You replace the parts which the library author does not known how you want to be. One of the policies would be a DoNotThrowPolice, which will require you to check the IStatus. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 22:08, Adriano dos Santos Fernandes wrote: But an (client) application wants to generate exception when accessing the API, and we do not know in advance what's the good classes for each project. And we'll never know. This is not our business, IMO. Some may use like Firebird, an Exception not inherited, others wants std::exception, a Qt-based project would want another one... This is for the higher level wrappers to care about. For example, IBPP throws its own exceptions. Firebird driver for Qt may have its own exceptions. And so on. We either forget about exceptions completely, or throw some partially abstract class (thus forcing users to implement the exception before being able to compile), or maybe go for the policies you described. That said, I'd rather resolve the other issues first. Even a no-exception API may be good enough for the time being, we can offer something better later. Dmitry -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 16:03, Dmitry Yemanov wrote: We either forget about exceptions completely, or throw some partially abstract class (thus forcing users to implement the exception before being able to compile), or maybe go for the policies you described. That said, I'd rather resolve the other issues first. Even a no-exception API may be good enough for the time being, we can offer something better later. One of the current problems (not major, but surely a problem) is the manual usage (init, set, catch, throw) of IStatus in our code. An integrated approach (who throws from IStatus, catchs and set IStatus) is very welcome. However, there is a prerequisite for this. IStatus should well manage its memory. I had to use circularAlloc in DdlNodes.epp because of its problems, and this is very bad. I'm afraid of all QualifiedName::toString calls. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On Aug 11, 2014, at 2:40 PM, Adriano dos Santos Fernandes wrote: On 11/08/2014 15:29, Tom Coleman wrote: I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL. There is never any case where I would want to see std:exception. Could it be time to start thinking about burying this idea that is looking more and more like a sacred cow? Then the chances of not wanting a FbException (not inherited from std::exception) are also very high. This is what polices are for. You replace the parts which the library author does not known how you want to be. One of the policies would be a DoNotThrowPolice, which will require you to check the IStatus. The interfaces all rely on returned status codes. At the interface level all I need is some indication of pass/fail, and some indication of why the operation failed. At the client level I have no interest in debugging the database. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 21:13, Adriano dos Santos Fernandes wrote: An integrated approach (who throws from IStatus, catchs and set IStatus) is very welcome. I would suggest a very simple approach: push IStatus out of engine, just throw exceptions there. Leave catching and converting exceptions into IStatus to border guards. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 16:19, Dimitry Sibiryakov wrote: 11.08.2014 21:13, Adriano dos Santos Fernandes wrote: An integrated approach (who throws from IStatus, catchs and set IStatus) is very welcome. I would suggest a very simple approach: push IStatus out of engine, just throw exceptions there. Leave catching and converting exceptions into IStatus to border guards. No. Providers and plugins should work when compiled by different compilers and being in different libraries! Make things as simple as possible, but not simpler - Albert Einstein Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 21:28, Adriano dos Santos Fernandes wrote: No. Providers and plugins should work when compiled by different compilers and being in different libraries! That's why border guards must stay between engine and plugins. As well as between Y-valve and outer world. Guards between Y-valve and providers are questionable. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 16:37, Dimitry Sibiryakov wrote: 11.08.2014 21:28, Adriano dos Santos Fernandes wrote: No. Providers and plugins should work when compiled by different compilers and being in different libraries! That's why border guards must stay between engine and plugins. As well as between Y-valve and outer world. Guards between Y-valve and providers are questionable. You told before (and now) as y-valve is part of each provider. That's not true. Y-valve is a concrete implementation of the provider API, and is part of the client library. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
You may be more interested in why something failed than just that it failed. An error mechanism should play nicely with the status vector to expose as much -- or as little as the user needs. Sometimes an error code is enough, sometimes a full formatted compound message is required. But a second call to pick up the last error would probably make almost every one happy. On Aug 11, 2014, at 4:14 PM, Tom Coleman tcole...@autowares.com wrote: On Aug 11, 2014, at 2:40 PM, Adriano dos Santos Fernandes wrote: On 11/08/2014 15:29, Tom Coleman wrote: I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL. There is never any case where I would want to see std:exception. Could it be time to start thinking about burying this idea that is looking more and more like a sacred cow? Then the chances of not wanting a FbException (not inherited from std::exception) are also very high. This is what polices are for. You replace the parts which the library author does not known how you want to be. One of the policies would be a DoNotThrowPolice, which will require you to check the IStatus. The interfaces all rely on returned status codes. At the interface level all I need is some indication of pass/fail, and some indication of why the operation failed. At the client level I have no interest in debugging the database. -- 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
Re: [Firebird-devel] New Interface
On Aug 11, 2014, at 3:36 PM, Jim Starkey wrote: You may be more interested in why something failed than just that it failed. An error mechanism should play nicely with the status vector to expose as much -- or as little as the user needs. Sometimes an error code is enough, sometimes a full formatted compound message is required. But a second call to pick up the last error would probably make almost every one happy. Exactly. In fact I had this type of Explain Last Error call implemented somewhere, but I haven't been able to locate it. If and when I do I'll know which database I used it on. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
On 11/08/2014 16:57, Tom Coleman wrote: On Aug 11, 2014, at 3:36 PM, Jim Starkey wrote: You may be more interested in why something failed than just that it failed. An error mechanism should play nicely with the status vector to expose as much -- or as little as the user needs. Sometimes an error code is enough, sometimes a full formatted compound message is required. But a second call to pick up the last error would probably make almost every one happy. Exactly. In fact I had this type of Explain Last Error call implemented somewhere, but I haven't been able to locate it. If and when I do I'll know which database I used it on. Always remember that internally, the old API is an user of the new API. If it can do easily, so you can do the same you were doing if you start to use the new API. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] New Interface
11.08.2014 21:43, Adriano dos Santos Fernandes wrote: You told before (and now) as y-valve is part of each provider. That's not true. Not true even that I ever told that. Read carefully and you'll see that I name completely separate parts: outer world, Y-valve, providers, plugins. What I use to forget about, is a network listener which from some POV can be considered to be in outer world. And I repeat again that guards should stay on these borders: Y-valve-outer world, Provider-plugin. Guards between providers and Y-valve may be missed because nobody ever will write third-party provider in alien language. I saw it in my crystal ball. -- WBR, SD. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
