FWD » Core Development » Database

Requires binary TRPL as a pre-requisite, since conversion will have to occur at runtime, on the fly.

We need to determine whether dynamic database features are scope-agnostic in terms of resolving database references; i.e., do we need to keep track of which buffer names should be promoted based on the sequence of open buffer scopes at the time a dynamic feature is invoked? This is done by the SchemaDictionary at conversion time for static buffer references, to enable disambiguation of buffer name references. Are dynamic database features also aware of this scoping? We will need test cases.

If we do find we need to account for buffer name promotion at runtime, note that all per-context buffer scope information is maintained by the BufferManager, so we could get it from there on demand, if necessary (with some changes to that class).

Note that any use of conversion features at runtime will require the use of existing or new conversion rule-sets and configuration information. Since we don't expect the entire conversion project to be available on a runtime installation, any such resources will need to be added to either the p2j.jar or, if customer-specific, to an application jar file. This is not critical for an early working version, but it should not be precluded by our design and implementation.

To clarify:

1. We are not going to use a binary implementation of TRPL for our first implementation.
2. We don't want to require the entire conversion process to be used, when we only need to convert small snippets of code/expressions.
3. The progress.g already has the expr rule that is a valid entry point for use in parsing a single expression.
4. Re-use the TRPL conversion rulesets as much as is possible.
5. Make ruleset changes as needed to allow common rulesets to differentially process depending on whether used in the full process or the dynamic database processing at runtime.
6. I expect that some custom rulesets will be needed to manage the overall dynamic database runtime conversion process. I just want those to reuse as much of the common code as is reasonably possible.
7. Long term, we want the standard rules to be loaded from the p2j.jar instead of from the file system.
8. Long term, we want the customer-specific rules and the customer-specific project configuration (e.g. p2j.cfg.xml) to be loaded from the customer's application jar.