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