Ok, thanks, so if I get you right:
* E4 Common API effort is different and has nothing to do with common
view effort.
* Common view effort is an "add-on" and not meant to replace unique
views.
So, with DSDP / RSE we may want to think about contributing to the
Common
View effort in the 3.x Stream but keep our old APIs and even old Views
intact --
it would just be an additional view on the same connections that we
already have.
One thing that I'm concerned about in the Common View effort when it
comes
to RSE, is that in RSE we allow the same remote element to show up
multiple
times in the view (if multiple user-defined filters select it). This
feature has been
quite some pain for us in the past and I'm afraid that the Common
Navigator
would have difficulties with it. (e.g. refresh remote element X: Will it
in fact
refresh X under both parents #1 and #2)?
I'd appreciate your comments on that situation. I'm going to post the
same
question on the bugzilla bug [1]
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=252239> related to the
common viewer effort.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=252239
Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, October 27, 2008 5:22 PM
To: E4 developer list
Subject: [eclipse-incubator-e4-dev] Re: E4/connection management
discussion
Hi Martin...
Yes, I saw Konstantin's posting on Friday and left him a
comment. I am in favor of having a view where multiple content types can
be shown in a single place -- i.e. the Servers view content and the Data
Source Explorer content. I think having the option of using a shared
view instead of individual views has a ton of merit, especially in RCP
applications that are more space-conscious than your usual Eclipse
plug-in IDE approach.
What I'm concerned with is that he's shooting for replacing the
Servers view and Data Source Explorer views with this common view. I
think this should be available as another option to users (and used
heavily in WTP where such a view makes sense), but that the DSE in DTP
should remain a unique, targeted view.
If I install DTP, I only want to see Database-type information
in my environment.
If I install WTP (which includes DTP), I want to see a shared
view that includes Servers and Databases. I see this as especially key
in WTP-related perspectives.
However in DTP perspectives, even with WTP installed, I may
still only want to see Database-type information.
After working with the Common Navigator Framework the last
couple of years in various forms, in my experience there isn't a great
way to have a view automatically enable/disable different content
providers. You can do it, but it's a royal pain to get that far down the
food chain using the CNF API.
If the goal is to provide a more united view where one is
appropriate, I'm all for it. If the goal is to replace all unique views
(in this case the Servers and Data Source Explorer views) across the
board, I'm less inclined.
I probably just threw a whole lot of wood on this fire that will
come back to burn me today. :)
As for the common connection management API, I've been
investigating how to use the ECF APIs as time allows with Scott Lewis'
help, so it's not dead. Just trying to explore options.
--Fitz
Brian Fitzpatrick
Eclipse Data Tools Platform PMC Chair
Eclipse Data Tools Platform Connectivity Team Lead
Staff Software Engineer, Sybase, Inc.
"Oberhuber, Martin" <[EMAIL PROTECTED]>
10/27/2008 06:30 AM
To
"E4 developer list" <[email protected]>,
<[EMAIL PROTECTED]>
cc
Subject
E4/connection management discussion
Hi Brian,
How does the "Common Servers View
<http://lt-rider.blogspot.com/2008/10/common-servers-view-for-eclipse.ht
ml> " blogged by Kosta today [1]
<http://lt-rider.blogspot.com/2008/10/common-servers-view-for-eclipse.ht
ml>
relate to your efforts of a common connections API in E4? Is the
idea of an E4 connections API still alive?
[1]
http://lt-rider.blogspot.com/2008/10/common-servers-view-for-eclipse.htm
l
<http://lt-rider.blogspot.com/2008/10/common-servers-view-for-eclipse.ht
ml>
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm <http://www.eclipse.org/dsdp/tm>
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 7:54 PM
To: E4 developer list
Cc: Eike Stepper
Subject: Re: [eclipse-incubator-e4-dev] nextsteps 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 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
09/23/2008 11:48 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,
[EMAIL PROTECTED] 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 <[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
>
_______________________________________________
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
