Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Re: ECF for the terminal....

Hi Michael,

Michael Scharf wrote:
Hi,

I am working on the DSDP->Target Manager->Terminal Emulator.

The starting point was a contribution by windriver, the
terminal from our commercial product. We refactored and
restructured it to get a better architecture.

The terminal provides a basic vt100 emulation. We have connectors
for ssh, telnet and serial connections. There is a view that
uses the terminal widget. You can connect a terminal to one of the
connectors provided by the extension point.

After this basic restructuring of the existing code, we
want to enhance the terminal. One requirement is to allow
file transfer over a given connection. So, I started
implementing an output stream decorator where you can get a
intercepting stream. And we have thought about allowing to
decorate the streams between remote an the terminal....

Well, wait a minute. Isn't that the kind of problems
ECF is supposed to solve? Maybe it makes sense to base
our connectors/connections on ECF.

The next problem we have is with the contributed connectors
(for ssh, telnet and serial). We have our own extension mechanism
to contribute connectors and to activate them as late as possible.

I wonder how ECF solves the problem of settings for connectors.
Simple example: given the ssh connector. To connect, you need
a use-name, password and an ip-address.
In general, connection through ECF is done via the IContainer.connect 
call [1].
The IContainer.connect call takes two parameters:

1) an ID instance that identifies the remote target [2]. ID's can have all different types, and in fact ECF exposes a namespace extension point (org.eclipse.ecf.namespace) that allows providers and others to define new namespaces (which are the factories for creating ID instances for a given Namespace). So for a normal ssh connector, the ID would typically contain the hostname/ipaddress, username, optional port (probably embedded in a URL underneath the ID would be a good way to go...e.g. ssh://username@host:port. Note: The ID can be used to address a peer, a server, OR a group (e.g. think multicast address for javagroups provider, or JMS pub/sub group for JMS provider, etc).
2) a IConnectContext instance [3].  The IConnectContext gives a way for 
callers of IContainer.connect to contribute an arbitrary set of 
callbacks, that can be used by the provider (the actual implementation 
of IContainer.connect(ID,IConnectContext)) to callback into UI or other 
code to collect password info, or other info needed to secure the 
connection.
Once it is connected, you
get back two streams to communicate with the remote site.
But:
- How would the log-in dialog for ssh come from?
With a container instance that support ssh, the login dialog can either 
be presented prior to calling IContainer.connect(ID,IConnectContext) OR 
it can be provided inside one of the callbacks inside the IConnectContext.
- How to connect without dialog?
Provide the password directly in the callbacks inside of IConnectContext 
 rather than a block for opening a dialog, etc.
- How to persist the settings for a connection?
This (persistence with Equinox) has been outside the scope of ECF.  That 
is, we've left it to examples/applications (including our own) to manage 
the persistence of IDs and/or passwords/other user identification, 
account info, and credentials.  Some have put this information in the 
preference store, others have managed it in their own way (e.g. with 
files on disk, etc).
With the recent work on secure storage using JAAS and Equinox (i.e. in 
M6 new and noteworthy), we are contemplating adding a bundle to persist 
and manage ECF info (i.e. IDs and passwords/other credentials) in a 
secure user storage [4] as well as associate ECF accounts (represented 
as IDs/Principals and credentials) with an authenticated JAAS Subject.
But we haven't gotten to that yet.  It would be a nice component/project 
though, as now that the secure storage and JAAS login is in Equinox, it 
should be straightforward to associate IDs/Principals (ID interface 
extends java.security.Principal) to an authenticated Subject (user) via 
Subject.getPrincipals() and Subject.getCredentials().
- How is lifecycle/state management done?
In ECF IContainer instances represent the 'session' or 'connector' 
concept.
WRT the lifecycle, all IContainer instances are created via a 
IContainerFactory (which is also exposed via OSGI singleton service). 
They are also managed by an IContainerManager (which is also exposed via 
an OSGI singleton service).  Both of these interfaces are also exposed 
via methods on a single ContainerFactory [5].
IContainers can be connected (via IContainer.connect) or disconnected 
(via IContainer.disconnect()), also they can have listeners 
(/IContainer.addContainerListener(IContainerListener).  These listeners 
are notified when
1) Connection

a) Before connection is attempted (IContainerConnectingEvent)
b) After connection successfully is made (IContainerConnectedEvent)

2) Disconnection

a) Before disconnection is attempted (IContainerDisconnectingEvent)
b) After disconnection happens (IContainerDisconnectedEvent)

3) If disconnection occurs asynchronously (IContainerEjectedEvent)

a) Disposing (IContainer.dispose() called...IContainerDisposeEvent)

Clients can determine the connect/disconnect state of an IContainer by calling IContainer.getConnectedID(). If null, the container is not connected. If non-null, the ID returned indicated what target the container is connected to.
- How are errors handeled?
It depends upon the type of error and the capabilities of the provider 
(e.g. their error detection capabilities).  For errors upon 
connection/disconnection of IContainer instances, 
ContainerConnectExceptions are thrown.
For IContainers that implement IReliableContainer [6] (a sub-interface 
of IContainer) they provide a stronger contract of failure detection and 
reporting (done via IContainerListeners)...i.e. in the case of network 
partition/dropped connections.
Now, we haven't yet said anything about actual data delivery/messaging, 
etc...and you won't find any methods on IContainer to that effect.  The 
reason for this is that *all* actual communications is done via 
container adapters, which are retrieved via an IContainer instance (e.g.)
IChannelContainerAdapter adapter = (IChannelContainerAdapter) 
container.getAdapter(IChannelContainerAdapter.class);
if (adapter != null) {
// use adapter to create messaging channel
    IChannel channel = adapter.createChannel(...);
    channel.sendMessage(...);
}

If you want to see a diagram of the relationship between containers, container adapter APIs, and ECF provider implementations see the slides here [7] page 10.
ECF has a number of container adapter APIs...datashare for asynchronous 
messaging to a named channel, filetransfer for async file transfer (used 
by p2 for downloading artifacts for install), presence (for IM/chat), 
discovery (for dynamic service discovery), remote services for 
transparent or explicitly accessed remote OSGi services, etc.  See here 
[8] for more info and docs about each of these APIs.  It's completely 
feasible/good for other APIs and/or implementations to be created by 
others...and we would be very happy to see this.
I have seen some presentations on ECF and I am pretty sure
ECF has solutions for my problems. But I never did a tutorial
or tried to implement anything on top of ECF. I fell like a manager,
knowing (vaguely) what ECF can do, but totally missing the details
and the knowledge how to do it.
We are (still) woefully lacking in tutorials and overview/tutorial-level 
docs...we know that.  I will make a concerted effort to do more of this 
myself.  But we do have a fair number now of examples and test cases for 
the various APIs [9] and the plugins that have 
'org.eclipse.ecf.example[s].* and org.eclipse.ecf.provider.* do give 
some useful code examples.  Please let us know which areas you are most 
interested in (i.e. which adapter apis, and/or which 
providers/protocols) and we will try to provide helpful pointers.
Is there an example/presentation/docu I can look at to
get started on this?
I would start with the test code for the APIs of interest (e.g. 
datashare), and/or some of the examples (e.g.  [10]).  Please let us 
know what else you are interested in doing, and we can hopefully guide 
further as we work on the overview and tutorial-level framework docs.
Thanks,

Scott

[1] http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/IContainer.html
[2] 
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/identity/ID.html
[3]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/security/IConnectContext.html

[4]
http://download.eclipse.org/eclipse/downloads/drops/S-3.4M6-200803301350/eclipse-news-M6.html#Equinox

[5]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/ContainerFactory.html

[6]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/IReliableContainer.html

[7] http://www.eclipse.org/ecf/presentations/eclipsecon2008/longtalk134/ecf_eclipsecon2008_134.pdf
[8] http://wiki.eclipse.org/ECF_API_Docs

[9] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/tests/?root=Technology_Project
[10] 
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/examples/plugins/?root=Technology_Project



Back to the top