[
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/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
