Thursday, December 15, 2011

Consider release and catch of graphs

The machine says, in default, when a TE strand opens a graph on a table, they own the table. So, when some descendent strand gets the URL event, it packages up the descendant graph and sends it off too http put binary land.  The descendant filter chain that caused the release goes to ready and is ignored by the machine, never part of the event drill down again, until a return url event occurs.  On a return url graph, the machine will locate the filter context, and set it unready with the attached graph. Seems like a no brainer in the whole version 2.0 series because we don't do parallel and we don't share output tables.

And, through the whole 2.0 series, tie the database to the machine instance, database name is constant, keep that simple and out of the picture.  On variable expressions, try to get hold of the sqlite3 expression analyzer, at least check if the machine can use it.  Otherwise, import a ready to go version, just adapt it to key word reads and writes.  Variables defined where they are first used?  Any expansion of the set of link operators ()*?,.$:!_, means adding some lines to the command line app. The parser is designed for ad hoc short cuts in TE syntax, things that make common sense to the client. Variable expression sequences get a free array/variable/domain/int_immediate pointer in the triple? no?

On the Dublin Core, just look for a package that can be a set of overload methods. Whatever the package purports to do, it can do it in G!

Another, the Huffman encodes. Reserve a bit in the link field for Huffman encodes, that is a huge money maker for database/web geeks, targeting the templates with specialized display, maybe adapting jquery to template formats in the web. A jquery dynamic ontology widget would be very nice. The machine could very likely spin out jquery syntax without much problem.

No comments: