[teiid-dev] Connector supplied metadata
Steven Hawkins
shawkins at redhat.com
Fri Jul 10 16:14:50 EDT 2009
An addendum to the timeline, there wasn't an updated version of the plan that was sent to the dev list. The internal version was just forwarded to a wider audience prior to the dev call.
----- Original Message -----
From: "Steven Hawkins" <shawkins at redhat.com>
To: "Steve Jacobs" <sjacobs at redhat.com>
Cc: "teiid-dev" <teiid-dev at lists.jboss.org>, "Ramesh Reddy" <rareddy at redhat.com>
Sent: Friday, July 10, 2009 2:19:25 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Connector supplied metadata
Here's my understanding of the timeline. An initial internal revision of the 6.2 plan was sent out for comment from TDM and PM. That plan already was shaped by input from the TDM/PM post internal discussions focused on the next 6 months. After some updates it was sent to the dev list, which kicked off an internal call. Based upon that call the connector metadata feature was elevated in priority - with the larger metadata roadmap goal still in place. After the updated plan was sent out, there was a dev list discussion about that priority change as well as a conversation with the TDM. The development consensus at large (see emails by Van and others) was that "this is a useful and desirable feature" and since it was determined to not be negatively impactful on the rest of the 6.2 schedule, I was inclined to move ahead.
Additional comments:
Yes the connector metadata feature purposely "narrowly scoped". If it were not, it should/could not have been done in the 6.2 timeframe.
It does not detract from a long term metadata story around alternative persistent forms of metadata. We are merely elevating a previously opaque metadata api for programatic use - rather than just loading through indexes. I know that is not exiting or grandiose, but it doesn't need to be. Without dramatically changing our system table/metadata connector logic, or breaking designer integration in a deep manner, this is the best that we can do. If anyone has issues with the code, please comment on the JIRAs.
I don't want to see this conversation take negative tones. There's no blame shifting, and complaining is welcome. The major qualms as I understand it is that John primarily believed that this feature negatively impacted the "value proposition" of Teiid and that he wanted it more clearly tied to a larger metadata roadmap. Even though I thought I was clear in that the latter was not an issue, for John it still was. To be even more clear however, we do now have the beginnings of a proper object representation of metadata that should eventually be used as the master representation of metadata, whether it's built programtically, parsed from ddl, or loaded from an index file. I'm not sure how to address the concerns as to the value of this feature. It gives us a story of "integrate your databases (and text files) in 5 minutes or less", which allows Teiid to finally be usable as a standalone download. And there's absolutely nothing about this approach that prevents "up sale" to the designer. The connector metadata can be obtained through an importer and will be (nearly) identical.
----- Original Message -----
From: "Steve Jacobs" <sjacobs at redhat.com>
To: "Ramesh Reddy" <rareddy at redhat.com>
Cc: "teiid-dev" <teiid-dev at lists.jboss.org>
Sent: Friday, July 10, 2009 1:23:00 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Connector supplied metadata
Ramesh Reddy wrote:
> Also, 6.2 list is based on the product discussions with TDM and PM.
>
Sorry, but that statement is not correct with regards to this feature.
The 6.2 list that was made available to TDM and PM included a "stretch
goal" to develop "a definitive plan around Teiid owned metadata - both
for SAP-like functionality (Connector exposed metadata) and for our
persistent form, which has already been on introduced as a topic on the
dev-list."
Ken and I were as surprised as anyone to see that change to a required
feature in 6.2. If the R&D call made it apparent that this goal needed
to be pushed forward, that's great, but no blame shifting please. When
I saw the item, developing a plan sounded like exactly the community
process that John is expressing his concerns about.
Steve
> I know, we need to get better at this, it's not late. So let's hear
> technical discussions around the feature rather than complaining.
>
> Ramesh..
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
>
_______________________________________________
teiid-dev mailing list
teiid-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
More information about the teiid-dev
mailing list