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
-
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
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
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
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
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
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
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
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 :
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
--
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
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
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
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.
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
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
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
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
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
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
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_
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
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
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
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
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
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
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,
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
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
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:
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
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
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
--
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
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++
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
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.
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
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
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
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
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
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
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
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
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
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.
--
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
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
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
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
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?
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
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
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
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
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.
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
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
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
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
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
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
64 matches
Mail list logo
