Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] next steps for the E4/connection management discussion 
Hi Brian,

brian.fitzpatrick@xxxxxxxxxx wrote:


<stuff deleted>
And we should look at ECF as a potential (especially as it is used in P2 already and been through the wringer!). We just have to be careful to make sure we keep a compatibility layer in mind for any existing frameworks that eventually move this way (including DTP, which has a lot of commercial code at Sybase and IBM already written against it).
Good point. I'll assert that this should not be a problem, because of ECF's provider architecture and extensibility. The ECF core IContainer api doesn't say *anything* about the actual protocol-specific communication (i.e. everything other than connect/disconnect). Rather it just exposes getAdapter(<intf>) for clients to get access to their own APIs at runtime. So I would imagine that the easiest/quickest way to retain backward compatibility for existing codebases is to expose an interface that they use (e.g. channel, stream, etc), and then make a reference exposing that interface available via their provider/implementation of IContainer.getAdapter(<interface>). It's even quite possible that some of these adapter APIs would want to become new API. Of course, if the apps/providers fit into existing ECF APIs (e.g. IChannelContainerAdapter, IStreamContainerAdapter, IPresenceContainerAdapter, IDiscoveryContainerAdapter, etc) then they can/could implement those...but they don't have to.
Of course if people want more input about this then I would be happy to explain further, or point to existing examples/impls, but I don't want this to become more tedious than it is for those that don't care...so I'll stop there. 

Scott



--Fitz

Brian Fitzpatrick
Eclipse Data Tools Platform PMC Chair
Eclipse Data Tools Platform Connectivity Team Lead
Staff Software Engineer, Sybase, Inc.



*Scott Lewis <slewis@xxxxxxxxxxxxx>*
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

09/23/2008 11:23 AM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>


	
To
	E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
	Eike Stepper <stepper@xxxxxxxxxx>
Subject
Re: [eclipse-incubator-e4-dev] next steps for the E4/connection management discussion 



	





Hi Brian/all,

brian.fitzpatrick@xxxxxxxxxx wrote:
>
> <stuff deleted>
> > Though we didn't come to any solid conclusions, it seemed very evident 
> that there's definitely a need for some sort of cross-project
> connection management framework in the E4 timeframe.

Agreed.

>
> > Since the meeting, I was contacted by Eike Stepper from the CDO Model 
> Repository and Net4j Signalling Platform projects. She would like to
> contribute to the conversation and at least keep informed of our
> progress, so it's good to know that outside of the immediate E4 group
> we have interested parties. Not sure if she'd like to demo their
> current frameworks or not. (Eike, do you want to chime in here?)
FWIW, there's an enhancement request to create an ECF provider using Net4j: 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406

...so that Net4j capabilities can/could be accessed via ECF-exposed
common APIs (e.g. for connection management).

Just FYI...last I checked, Eike was male.  Hi Eike.
> > =High Level Goals= 
>
> At a minimum, it would be helpful to come up with a common API for
> connection management and persistence.
>
> Some simple use cases might include:
> > * Connecting to a unique connection object (database, system, etc.) 
> * Disconnecting from a unique connection object
> * Retrieving the raw connection class from the managed connection object
> * Managing connection properties (such as connect/disconnect state and
> any custom properties for the connection type)
> * Managing a list of connections, both connected and disconnected
> > More complicated use cases might include: > > * Connection timeout 
> * Backward compatibility

I don't have any criticism of use these use cases, although we might
want to amend with:

* Representing different types of connections (i.e. for different
protocols) and extensibly accessing protocol-specific capabilities
* Extensibly representing addresses in a common way across different
addressing systems (e.g. ID/URI, etc)
* Authentication security with different protocols/authentication schemes
* Supporting other environments (e.g. Equinox-based servers)

>
> I think some level of UI consistency is still an important factor
> also. Maybe if we don't all have the same UI components, we could all
> agree on a consistent set of UI-based connection management tasks? Or
> a consistent look and feel even if we're not all exactly the same?

Thoughts?

Although I agree that UI consistency is important, I hesitate to
consider it part of a connection/connection management API. Why? Because several of the things we seem to be looking for in a connection 
framework (connection management, transport independence) are logically
separate from a user interface for creating/configuring connections
(i.e. stuff needed so connection to external process can be
established).  I say this because there are plenty of use cases (i.e.
those Brian lists above) that involve connection management that
can/could have no user interface at all for some applications (e.g.
client apps that automatically connect to a number of IM accounts upon
app startup or server-based apps that create connections for
server/services, etc).

I do think that there can/should be work on UI for connection
configuration and usage, and we (ECF) have done some small amount of
work in this area.  We've created some common/reusable user interface
components (e.g. connection dialogs and wizards), and we have some ui
extension points (configurationWizards and connectWizards) that make it
easier for new provider/protocol impls to introduce their own UI for
connection creation/configuration.  And I'm in favor of the notion that
EMF models could be created/used to construct config/connect UIs...we
just haven't done that ourselves so far.

But I'm not in favor of pulling in UI dependencies specifically for a
'connection framework'...at least partially because a connection
framework (like ECF's IContainer APIs) can/is being used in entirely
different environments...like Equinox-based server applications.  I know
that this group is not focused on Equinox-based server applications, but
I do think considering the use of connection frameworks in those
environments will result in better separation of concerns at the
bundle/api level for a connection framework.

Also, I would request that any effort to define a new connection API
first take a look at and try out ECF's IContainer API for satisfying
these use cases.  I think it can/could meet all the use cases I've seen
so far on this list, and I think it would be a terrible shame to spend
significant effort redoing much of what we've done (and is available as
part of p2-based Equinox).  Also, if there are use cases that we've not
addressed (so to speak :), then of course the API can/will be migrated
forward as needed.

Scott


_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev


------------------------------------------------------------------------

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

Back to the top