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


Hey Scott...

I would definitely like additional information about your APIs, and examples and samples would be very helpful. Perhaps we shouldn't bore people with that on the mailling list however.

Can you create a Wiki page and link it to the E4/Connection Management discussion where you document some of the high points of the API and provide some examples? Links to existing code and samples would be fine if you have them.

Thanks a ton!
--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:48 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,

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
>  

_______________________________________________
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