Hi again! Thanks Scott!
Sorry Eike! (Cowering in embarassment) All of what you said sounds fine Scott... The extra use cases are great and should definitely be considered. As far as UI... I see your point, and think we should definitely focus on the framework/API side long before talking about UI (and it should most likely be a separate framework, since we definitely want to keep UI/non-UI code as separate as possible). But I don't want it to fall off the table as a talking point. 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). --Fitz Brian Fitzpatrick Eclipse Data Tools Platform PMC Chair Eclipse Data Tools Platform Connectivity Team Lead Staff Software Engineer, Sybase, Inc. Scott Lewis <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/23/2008 11:23 AM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc Eike Stepper <[EMAIL PROTECTED]> Subject Re: [eclipse-incubator-e4-dev] next steps for the E4/connection management discussion Hi Brian/all, [EMAIL PROTECTED] 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 [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
