[teiid-dev] 6.2 planning

[Steven Hawkins]

There are three main engineering goals for the 6.2 release cycle (~12 weeks):
To provide legacy server features to the embedded deployment, to provide a simple client/server runtime mode, and to provide metadata through connectors for a simple query mode.

At a high level our requirements are:

1. Port the Membership, Authentication, Session, and Tracking (CommandLogging) services for use in embedded.  This is straight-forward except for the authentication service, which will require treating the only source for authorization information as the vdb itself in the form of an associated xml file (note that we are not doing something new here yet, the schema for defining policies was introduced in 5.5.1).  This is covered by TEIID-663 (with subtasks TEIID-664 - 667) and TEIID-668.

2. Provide a Java main that will launch the "server" with a socket transport. - Needs a JIRA

3. Ensure adminapi/admin shell coverage of all exposed functionality - the console should not be necessary for this release.  There is not a a JIRA for this as such, but needs to be addressed as service changes are made.

4. Modify the connector api to produce runtime metadata objects from source metadata.  This metadata facility will probably have a superficial resemblance to JDBC DatadataMetadata.  The QMI and other engine logic will need to be modified to support this "modelless" query mode. - Needs a JIRA

The assumption with all these is that the current server mechanisms for configuration and clustering are disregarded.  We are specifically not attempting to provide a clustered server that is feature/api compatible with legacy MetaMatrix.  This work should also have minimal to no impact on Designer's usage of Teiid embedded.  Any new work in designer would be a stretch goal only.

The engineering stretch goals for this release are:

1. Provide JOPR plugins for monitoring and additional adminapi functionality.  Van has initially indicated that he would like for these to remain out of Teiid proper until they seem usable wrt the release at some point much later in the cycle.

2. Have definitive plans around Teiid owned metadata in a persistent form, which has already been on introduced as a topic on the dev-list.

3. Re-implement file and database based artifact access through JCR (DNA) - with an eye toward using JCR as a means to provide "cluster" features, but that would still be api compatible with the embedded implementation (JCR backed by the filesystem).

4. Refine service loading/wiring/configuration in MC or other consistent container strategy.

5. Allow for pass-through ddl in both the single source and multi-source scenarios - TEIID-669

In this bucket as well is a task to provide a doc set around our legacy SOAP services and some proposed REST services in terms of how they can be implemented with JBoss projects with a loose coupling to Teiid.  This will be covered under its own JIRA with multiple subtasks covering prospective services use cases.

A 6.3 bucket has been created out of pushed 6.2 items and select issues in 6.x.  This will serve as the place holder for the further refinement of the new simplified server approach At the end of 6.3 we should have re-established our clustering story, a good story around configuration changes, fully incorporated JOPR, and carried-forward any lingering server features.

On the non-engineering side of things we have the requirements of:

1. Updating the server extension guide to cover things from an embedded/simplified perspective given the changes to command logging, membership domains, etc.

2. Update the connector developers guide - TEIID-104

3. Add the jdbc developers guide - TEIID-315

There are stretch goals of:

1. Adding additional screen casts covering a broader set of common uses.

2. Add more examples to the kit, especially highlighting use of non-relational sources.

3. Get Teiid as a recognized source in other products/projects - squirrel, dtp, hibernate, etc. 

Note there are missing JIRAs for a lot of these items and the priority may not yet be assigned correctly for items identified as requirements.  Devs and leads should feel free to help fill in gaps.  Let me know if there is anything that has been left out or what we should dive into a little more detail on.

Steve