[teiid-dev] Embedded Vs Server in the Designer

Ramesh Reddy rareddy at redhat.com
Thu Apr 29 15:07:44 EDT 2010


just changing the title of the email from last one..

On Thu, 2010-04-29 at 15:01 -0400, Ramesh Reddy wrote:
> On Thu, 2010-04-29 at 14:24 -0400, John Doyle wrote:
> > as part of the embedded Teiid for Designer which results from this
> > change, 
> No, this assumption is wrong. Designer can keep going on the same path
> as today, the only thing will change in this case is to designer to
> support the both layers. Designer team was already doing the similar
> technique for JDBC connectors from the earlier design, now, with this
> change it will apply to all the sources.
> 
> > its been proposed to me that we use DTP as the infrastructure to
> > create and manage connections to sources for metadata and embedded
> > execution.  
> The proposal is, if we want the user experience is to be consistent
> across different sources and different tools inside JBDS, we need to
> look toward DTP for connection management. If this not possible, then we
> need to see if we can expose a "import API" in the Teiid, so that user
> is only going to one place to create any connection for importing and
> previewing. Right now what we have DTP for JDBC sources, Custom for some
> (SF, XML) and may be none (TEXT, LDAP) etc. 
> 
> > In an earlier thread we discussed using DTP in this way (minus the
> > execution part) and decided it wasn't a good idea because it would
> > cause confusion for the user to have all of these DTP connections that
> > don't do anything in the DTP views/tools (I've since had a chat with
> > John Graham who says there is precedent for using DTP in this way,
> > although he agrees it is confusing).  One implication of this decision
> > would be that any connector that is to be executed in Designer will
> > need a DTP Connectivity plugin. 
> Based on the conversation, we share the same view. The benefits are more
> compared to the drawbacks. Yes, you are right about the connectivity
> plugin. The thought process for custom connector is user already knows
> how to connect to the underlying source. May be he uses JCA on one side,
> something else in the Designer. However if the user only has JCA way to
> connect to the source then he/she will be out of luck in the embedded
> scenario. Yes, this constitutes lot of work. 
> 
> >  This significantly raises the bar for any custom connector that is
> > not a modification of one of our connectors (eg, SQL translators for
> > JDBC).  It raises the bar not only in terms of effort, but it involves
> > a different skill set (eclipse develppment) that we did not require
> > before.  The alternative seems to me that you have to deploy to Teiid
> > test with your custom connector.  Perhaps this limitation is
> > acceptable, I just want to highlight it.  We can or course provide
> > examples, templates, etc to assist in this effort
> If we pursue this route, we could provide canned framework to develop a
> DTP plugin. You are correct in terms of limitations, may be they can be
> just happy in providing the text based data for previewing, and can do
> the real testing on the server. For example, XML connetion can use just
> a TEXT file in Designer for preview and use a SOAP call in the server.
> This offers us flexibly in switching connections.
> 
> Good questions, keep em coming.
> 
> Ramesh..
> 
> _______________________________________________
> 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