|[eclipse-incubator-e4-dev] Re: E4 towards generic connection management|
Hi Martin and all,Martin thanks for forward to me...I peruse the E4 list I don't/haven't kept up.
I also think this is a great idea. ECF in its core provides a completely generic connection framework. See short explanation below if interested. Further, ECF's core is in Equinox in 3.4 due to p2 usage of the ECF filetransfer API (which is based upon the ECF core) so is already present in Equinox+p2.
So please do let me/us know about such discussions and what we can do to help get to an E4 generic connection framework. I hope what we have in ECF can be of use...and of course we are migrating it forward all the time so can/will accept new requirements if/as they arise.
Thanks, Scott Short explanationFor ECF, connection == org.eclipse.ecf.core.IContainer interface. Around this, we have IContainerFactory, IContainerManager, IContainerListener/events, and IContainerManager listener. The factories are exposed as OSGi services and extension points. IContainer has semantics for connect/disconnect and extends IAdaptable. There is an extension point for defining IContainer implementations (aka providers). Addressing is provided by the ECF ID interface...like a URI but more general. There is also IIDFactory/Namespace apis as both services and extension points. There is nothing bound to any particular protocol or transport. We have a general set of interfaces (IConnectContext) that may be used for providing credentials upon connect.
URLs javadocs: http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/ API docs: http://wiki.eclipse.org/ECF_API_DocsIContainer javadocs: http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/IContainer.html
Oberhuber, Martin wrote:
Hi Brian,this sounds like a great idea. I'm CC'ing Dave Dykstal (DSDP-TM / RSE) and ScottLewis (ECF) here to broaden the discussion, as well as Doug Gaff from the DSDP PMC. For background, see http://wiki.eclipse.org/E4/Connection_FrameworksI think it would make sense if we prepare a conference / demo session tounderstand what we all have. You could showcase what DTP has, and I'd also be interested to see Sybase vendor-specific extensions of the DTP framework used for other kinds of connectivity. Others could probably also kick in and make some demo of their stuff.If that sounds good to you, could you propose a meeting time andScreen Sharing facility? I could offer using Wind River's Webex account but haven't used it myself so far so I'm not sure how well it would work for a shared demo session.In order to also add the technical aspect of DSDP-TM, we do havea lot of re-usable widgets, wizards and views for generic kinds of connections and the resources below them. But our code pre-dates the Common Navigator, so we don't have a CN integration yet. And, the kinds of connections that we've been managing are biased towards TCP/IP so they are not quite as generic as they could be. We do, however, have a concept of system types with pluggable subsystem kinds which proved quite usable so far.I fully agree that in a world where the "Network" is becoming moreimportant than the local client, a generic approach for the user to manage connections of all kinds will simplify user experience (and help reducing code duplication and bloat).Cheers,-- *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm------------------------------------------------------------------------ *From:* eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] *On Behalf Of *brian.fitzpatrick@xxxxxxxxxx *Sent:* Thursday, August 21, 2008 7:49 PM *To:* eclipse-incubator-e4-dev@xxxxxxxxxxx *Subject:* [eclipse-incubator-e4-dev] e4 beyond the ongoing UI conversations... Hi all... Though I appreciate all the great discussion going on around e4 and the UI work being done (though most of it is beyond me, not being an HTML/CSS guy, I do find it fascinating), I was wondering if there is room in e4 to focus on other parts of the Eclipse ecosystem as well. One of the issues IMHO across some of the major Eclipse projects is the issue of cross-project integration. This is especially evident (to me anyway) in terms of connection frameworks. The Eclipse ecosystem has many different types of "connection" frameworks. The CVS (Eclipse Platform), Remote Systems Explorer (DSDP-TM), Web (WTP), Communications (ECF), and Database Development (DTP) perspectives all have their own server/system connection management user interfaces and connection frameworks. WTP has been working with DTP to handle management of database connections, which is great, but it's just the tip of the iceberg.Within e4, we have a chance to settle on a common framework forconnection management and its associated UI. This would not only help out the user with a common look and feel across the Eclipse ecosystem for connecting to various systems, but it would allow adopters and extenders to take advantage of this common framework so they too would fit into the Eclipse-iverse more seamlessly to their own users.The connection framework within DTP, though used primarily forJDBC database connections at this point, has been used with great success in many other ways by Sybase products to connect to file systems, application servers, UDDI and LDAP repositories, and so on. I think it has great potential to fill the need for a common connection framework in e4.However, integrating will the other projects in Eclipse will betricky at best and require a great deal of collaboration from many interested parties.Do others see this as a problem that could be addressed within thee4 timeframe? Or am I way out of scope with this suggestion?Thanks--Fitz (aka Brian Fitzpatrick) Brian Fitzpatrick Eclipse Data Tools Platform PMC Chair Eclipse Data Tools Platform Connectivity Team Lead Staff Software Engineer, Sybase, Inc.
Back to the top