[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse-incubator-e4-dev] E4/connection management discussion
|
Hi Brian,
relate to your efforts of a common connections API in E4?
Is the
idea of an E4 connections API still
alive?
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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