For Architects
Oninit® MySQL-2-Informix — A Wire-Protocol Translator That Drops Into the Architecture You Already Have
Most “MySQL access to Informix” stories require either a parallel database, a heavyweight integration platform, or a per-application translator stuck onto the application stack. The proxy is a third option: a small wire-protocol gateway that lets the MySQL world talk to Informix natively, without changing the application or the database.
Architectural shape
A multi-threaded C daemon listening on the MySQL 4.1 wire. One pthread per accepted client connection, each holding its own Informix backend session. The translation pipeline is a five-step path — read the inbound packet, normalise the SQL, classify it, dispatch to a handler (built-in response, catalog SELECT translation, or passthrough to Informix), and encode the Informix result back into MySQL packets. The classifier and translator are pure C and verifiable independently of any Informix dependency, so the translation surface can be reasoned about without the database in the loop.
Two backends behind one contract
The proxy ships with two interchangeable backends behind a single internal abstraction. Both implement the same set of operations (connect, disconnect, execute non-row-returning SQL, execute SELECT through a cursor, execute INSERT / UPDATE / DELETE returning affected-row count, and run catalog-translated queries):
| Backend | Properties |
|---|---|
| m2ie | IBM Informix CSDK via ESQL/C. Reference implementation; uses the IBM-supplied client path. |
| m2is | Pure C against the SQLI wire protocol. No CSDK on the deployment host. The same SQLI library underneath is also used by the Oninit® Snooper. |
The two backends produce the same MySQL-wire output for the same SQL on most rows; a small documented set of behaviours where the SQLI-protocol backend is strictly more correct than the ESQL/CSDK reference is captured on the Backends page.
Stable contract for the application tier
The application tier sees a MySQL 4.1 server. The handshake negotiation is the standard one client connectors in the wild expect. Catalog statements (SHOW DATABASES, SHOW TABLES, SHOW CREATE TABLE, SHOW INDEX, SHOW GRANTS, SHOW TRIGGERS, SHOW CREATE VIEW, SHOW CREATE TRIGGER) return the rows MySQL tooling and ORMs already parse. CREATE TABLE rewriting is symmetric: the same type table that maps MySQL types to Informix on the way in is applied in reverse by SHOW CREATE TABLE on the way out, so schema introspection round-trips cleanly. INSERT into BYTE / TEXT columns from MySQL clients carrying binary payloads inline is handled by the proxy as a transparent wire-form rewrite under m2is; the application sees a normal INSERT round-trip.
Where it fits in the target architecture
| Pattern | Fit |
|---|---|
| Existing MySQL-only application picks up an Informix data source. | Drop the proxy in front of Informix; point the application at it. No driver swap, no connector change. |
| Off-the-shelf product whose connector list ends at MySQL. | Same shape — the product's MySQL driver connects to the proxy and reads / writes Informix transparently. |
| Container-native deployment with no IBM CSDK in the image. | Run m2is; the deployment host is pure C and depends only on libc + pthreads. |
| Cutover assistance during a long migration window. | Application keeps speaking MySQL; the proxy can be repointed at different backends without touching the application stack. |
Operational primitives
- One pthread per connection. Each connection holds its own Informix backend session, so a slow query on one connection cannot block the others.
- Pure-C front-end keeps the deployment surface small and the supply-chain story tight (no libmysql, no MySQL connector library on the host).
- Pure-C license-key validation (in-tree SHA-256 / HMAC-SHA256, no OpenSSL dependency).
- Both backends share a single configuration file and the ./m2i control script; choosing between them is a runtime environment variable, not a config rewrite.
- The portable SQLI codec is a clean drop-in for other tools and is the same wire-decoder the Oninit® Snooper uses.
Vendor and lock-in posture
The wire protocols on both sides are documented standards (MySQL 4.1 on the client, Informix SQLI on the server). The translation surface is a documented type table and a small list of catalog rewrites. No proprietary message bus, no managed service, no agent fleet. If the integration story changes later, the proxy is one process to remove, not a stack to dismantle.
Next step: a one-hour scoping call to map the proxy into the target architecture for one workload. Email support.info@oninit.com.