Thursday, December 15, 2011

G-Sqlite3 integration plans

If I were the lucky soul to make a business out of the graph machine, I would publish my plan for further sqlite3 integration. specifically I would focus on graph micro sequences being formatted closely to sqlite3 tokens. Here is what I mean.
Truth, in the machine, is a cross between TE syntax events and graph micro actions:
[Set of all syntac events] CROSS [set of all micro actions]

The CROSS is encoded in opcodes that exist in the filter context of each convolution.  The events are things like, overloaded, bounded domain, link match codes,  key word match code,default, gspew.  The opcodes, right now, specify 0 to 3 micro sequences to execute.  In the event loop, the event is encoded, and the loop drills thru the filter ascendant list trying to cancel all the event codes.  The opcodes might become part of an sqite3 query optimization, and intelligent bind, or a very fast call back on computed rows.  The best plan here is to constantly refer back to how  sqlite3 does it when expanding the opcode format.

I would think a TE 2.1 should be definable even as some unknown software geeks debus version 2.0. And the goal should be integration of transparent table jumps, more intelligent gfun callbacks, release and catch of graphs from machine to machine.  But always look to tight integration with the query optimizer in sqlite3.

No comments: