Jim,
> Would it be possible and desirable to have FreePascal as an embedded
> stored procedure/trigger language in some future release of Firebird?
> (I
> can't recall this having been brought up before, so I just start the
> ball rolling).
I did not check the current state of Java "plugin", but originally it
was not planned to change Firebird's DDL to be able to write something
like this:
CREATE PROCEDURE divide(a INTEGER, b INTEGER) RETURNS INTEGER LANGUAGE
JAVA AS
{
if (b == 0)
throw new MySuperException();
else
return a / b;
};
Instead it was supposed to be something like this (syntax might differ
now):
CREATE EXTERNAL PROCEDURE bla LANGUAGE JAVA EXTERNAL NAME
'org.firebirdsql.HelloWorld.sayHelloWorld';
This means that Java procedures were supposed to be compiled
externally. We have discussed the idea of compiling them on-the-fly and
store them in the database, but if I remember correctly, no decision was
made.
So, considering this all, there should be (theoretically) no problem of
compiling the code in Free Pascal as long as it will produce binaries
with appropriate entry points. That should be possible out-of-the-box
(at least it was discussed that way few years ago).
I personally think that at least two or three additional languages
should be supported: Pascal, JavaScript and possibly PHP.
> 2. End user considerations
> ==========================
> 2.1 A lot of developers that use Firebird program in Delphi. As
> FreePascal syntax is (almost) identical, these developers can easily
> port their code between the database and the application.
Why not allowing to code in Delphi as well?
> 2.2 FreePascal may be easier to learn than Java for some people and
> would make a nice alternative as opposed to e.g. including C or C++
Original idea was to allow to code in any language you like. If that
would be a language that produces directly executable code, the binary
should have looked like a dynamically linked library with certain entry
points. If that would be a VM or interpreted language, appropriate
plugin would be required.
> 3.1 Obviously, Firebird must allow running compiled code (as opposed
> to
> running code in a Java Virtual Machine), presumably in a form of
> dynamic
> library.
Yes, Java is more secure in this case. In the early versions of Java
plugin we have considered to create a standalone running process which
would execute the procedures and that would communicate with Firebird
using IPC. The reason, however was different at that time - we wanted to
provide Java also for Classic Server users and instantiating a JVM per
FB instance would be an overkill.
As far as I know, Oracle procedures are executed in a separate process,
and they are executed quite fast. So that should be possible.
> 3.2 Firebird must be modified to include (a stripped down version
> of?)
> the FPC compiler (or store the location of the compiler) and call it
> whenever the FreePascal source code in a procedure is changed.
> This might not be necessary for production servers as long as
> embedded
> Pascal code is compiled on developer machines and the resulting
> object
> code is loaded into the production database.
That was the main discussion - how to allow using different languages
in the DDL. If I remember correctly, no decision was made at that time.
I guess this is a bigger issue than to include FPC compiler.
But as I say, the idea was that entry points in the shared library
should be enough.
> 3.3 FreePascal will need to have some way to access, manipulate and
> return the data in the database and call other Firebird stored
> procedures, functions, etc. FPC already has good database access,
> including Interbase/Firebird support, but some kind of interface unit
> for direct access will need to be added.
That should be solved the same way it is solved for Java.
In few words, the shared library would get few function pointers during
initialization (therefore, you would need to have an "init" entry point
in DLL) from which it would be able to fetch database API. Previously
that was a list of isc_XXXX entry points plus two additional functions
to fetch db_handle and tr_handle for the current context. I guess
Adriano made this API object-oriented now, but the idea should be the
same.
> 3.4 FreePascal will need to use the Firebird memory manager. Using
> various memory managers is fortunately already possible in FPC.
Most likely yes, for Java that was not a big issue.
> 3.5 Most importantlY: it will probably require a lot of work on both
> ends to get this done. Fortunately, both Firebird and FPC have an
> active
> developer community with good communication and bug tracker systems,
> so
> this helps.
I guess the first version would be pretty easy to get implemented. The
biggest issue for the user acceptance I see the extending of the DDL
language, so that one can create a single DB script, from which the
procedures would be compiled, stored in the DB, could be backup-ed and
restored. Then security - when I created procedures on one host, backup
the DB and restore it on a different host, how do I ensure that the
restrictions of that host apply? Am I able to have some kind of a
sandbox for directly executable code (in Java I can have a security
manager that would protect the file or network access)...
Roman
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
