On Mar 29, 2010, at 11:49 AM, John Doyle wrote:
I didn't touch Dimension outside of all hands testing so long ago, so I don't really know if this is the opposite of what Barry described below or not. Dimension forced explicit VDB creation at the outset????
Yes, the was exactly the main concept Dimension introduced. The entire "workspace" represented a single VDB. There was no concept of "project". All model creation/editing/etc. occurred within the context of the VDB. Thus, the idea of having multiple VDBs that spanned a set of models, or thinking of it from a different perspective, a "workspace" where a single model could exist within multiple VDBs, didn't exist. Simpler mental model, less flexibility, and cheaper cost.
As I said before, I'm generally not in favor of hiding anything, but while we're thinking out of the box, and a hidden VDB is on the table, we could go in the other direction. Why not use a hidden VDB to preview ( I imagine this is what happens for a lot of targets when using Run As...) and standard eclipse Export paradigm to create the 'real' VDB. Get rid of the entire user gesture for New->VDB and the appearance of a VDB in the project view.
This comes at a cost in flexibility. As implemented today a user can create multiple different VDBs from a single Model Project, and in the implementation I'm describing Model Project = VDB. In that sense I don't really conder that we're hiding anything if we did it this way. I don't know if multiple VDBs from a single project is a use case anybody is interested in.
I agree with the direction you're suggesting here, but it's probably going to be much more than we can bite off for this next release. Talking to the GSS guys, it's a pretty common use case for a customer to want to share a model across multiple VDBs, so I think we'd also have to use Eclipse links to share models across projects so that changes may be kept in sync. This would visually look like Dimension, but add one extra layer to allow multiple VDBs in a workspace.
Regarding just preview, I think starting out we need to keep things as easy for the user as possible and add more advanced functionality only when asked for it. That said, it seems like the simplest, easiest user experience would entail using Ramesh's API additions and a single Teiid instance having workspace-wide scope regarding preview so the user doesn't ever have to worry about it. Assuming a Teiid is bundled and configured with the tooling, we would automatically make that the preview instance, avoiding even the necessity of any first-time setup by the user.