program, which helps student developers to contribute to various open source projects. We believe in providing students with interesting and useful tasks that Firebird users could also benefit from.
- Native PSQL debugger
Firebird has a DSQL/PSQL execution engine known as "the looper", which implements a state machine and executes the tree of nodes. For PSQL requests, basic debugging information is available, that maps every executon node to its corresponding source code (line/column info) and provides knowledge about local variables, etc. A mechanism of breakpoints is needed, along with provision to control debugging - attach to some session, set/clear breakpoints, retrieve call stack, retrieve values for local variables, etc.
Complexity: medium
- Customizable error/warning logging
A single firebird.log file logs all types of errors. The codebase should be reviewed to find all error reporting places and assign priorities (aka severity levels). An abstract interface should be developed to log errors/warnings. Its implementation should be plug-in based, for which the underlying infrastructure is in place. A default logging plug-in should more or less match the existing implementation, probably with prettier output and some configuration abilities. Alternative logging plug-ins may include integration with syslog, etc.
Complexity: easy
- Non-Firebird providers for external EXECUTE STATEMENT
The Firebird engine allows dynamic SQL to be executed in PSQL modules via the EXECUTE STATEMENT command. This ability extends to remote databases via the ON EXTERNAL clause. While the existing implementation supports access to Firebird databases only, feature was designed to be extendable. A provider library is needed, implemented to act as a gateway between the Firebird API and some external API. ODBC is preferred for a number of reasons: it is native code, it is cross-platform and it supports a variety of RDBMS via ODBC drivers. Other options could be considered.
Complexity: medium
- Full-text search (Sphinx based) integration into the engine
Back in 2008, the Firebird Project developed patches adding Firebird support to the Sphinx search engine. It wasn't really an integrated solution, just the first step towards that goal. Patches need to be updated (or maybe rewritten from scratch) to match the current Sphinx versions. Possibilities for integration of the real product, be it embeddable or side-by-side, need to be researched and implemented, including SQL support for full-text search queries.
Complexity: medium
- Machine-oriented audit/trace output
The Firebird engine has a built-in audit\tracing feature allowing pluggable modules to be used for logging events. The default plug-in distributed inside Firebird packages implements only text output, which is human readable but not really friendly to any automated processing. It would be a useful addition to implement alternative output format(s) that are machine oriented and allow easy parsing and special processing.
Complexity: easy
- Modern replacement for /examples
The Firebird distribution includes an example database and a set of API examples written in C. They were inherited from InterBase and now show their age. Also, Firebird v3 introduces a new object-oriented API that needs good examples. We suggest describing some application field that could be used for learning SQL and the API, designing and populating a new example database and implementing a set of source code examples demonstrating API usage. The preferred language is C++.
Complexity: easy
- Integration with external monitoring solutions
The Firebird engine has a number of built-in monitoring features, including the virtual MON$ tables and audit/tracing facilities. Some of them are good for immediate runtime monitoring, others are useful to perform any post-factum analysis. These features should be reviewed, new monitoring events could be suggested and implemented, hooks for external communication at runtime are to be designed and implemented, pluggable compatibility layers with well-known monitoring solutions like PerfMon or statsd/Graphite are to be developed.
Complexity: medium
- Isolated process-based sandboxes for external native code execution
Firebird allows execution of arbitrary user-defined binary code (external procedures/functions/triggers, BLOB filters, etc). However, this affects reliability and implies some serious security risks. It makes a lot of sense to isolate (optionally) the potentially dangerous code inside process-based "envelopes", aka sandboxes, to protect the Firebird server from unexpected crashes. Also, permissions for such sandbox processes could be limited to prevent any undesired activity.
Complexity: medium
- Customizable format for external tables via plugins/adapters
Firebird supports external tables in the predefined binary format (fixed-length rows). They are non-transactional and primarily used for user-level logging and export/import tasks.The whole interface to external tables could be redesigned to allow pluggable implementations of different table formats. One possible extension could be the CSV format; other options could also be considered.
Complexity: easy
- Design specification for tablespaces
Many RDBMS products have support for tablespaces - an ability to define multiple page storages and use them for specific database objects (tables, indices, etc). Firebird currently lacks this feature but it has enough of the necessary internals already in the codebase, e.g. a concept of page spaces. A complete implementation of tablespaces surely overflows the GSoC timeframes, but a proper design specification and patches implementing at least some of the required code parts look doable.
- OpenGIS support, R-tree design and implementation
GIS support is one of the top-voted but still missing features in Firebird. It's worth learning the OpenGIS requirements, design the missing parts and at least partially design and implement the effective searching structure (R-tree) as an alternative to the existing B-tree implementation.
Complexity: hard
References:
http://www.opengis.org/docs/99-049.pdf
- RedHat DLM plug-in replacement for Firebird lock manager
In the past, InterBase (Firebird's historical predecessor) worked on VMS operating systems and natively supported the VMS distributed lock manager (DLM). The VMS days are gone and Firebird has its native lock manager, still compatible with the VMS DLM at the interface level. Over the years, the VMS DLM reincarnated as OpenDLM and then evolved into RedHat DLM, and currently looks available in RHEL and CentOS at the kernel level. It would be an interesting challenge to figure out how much compatibility is preserved and what could be adapted to allow the RedHat DLM as a replacement for Firebird's lock manager.
for interesting tasks under the "New Feature" and "Improvement" categories and we are ready to discuss them as possible candidates for GSoC projects.
