Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » ECF for the terminal....
ECF for the terminal.... [message #622649] Fri, 04 April 2008 12:59 Go to next message
Michael Scharf is currently offline Michael Scharf
Messages: 297
Registered: July 2009
Senior Member
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. 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?
- How to connect without dialog?
- How to persist the settings for a connection?
- How is lifecycle/state management done?
- How are errors handeled?

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.

Is there an example/presentation/docu I can look at to
get started on this?


Michael
Re: ECF for the terminal.... [message #622651 is a reply to message #622649] Sat, 05 April 2008 18:27 Go to previous message
Scott Lewis is currently offline Scott Lewis
Messages: 964
Registered: July 2009
Senior Member
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/ecli pse/ecf/core/IContainer.html

[2]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/ecli pse/ecf/core/identity/ID.html

[3]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/ecli pse/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/ecli pse/ecf/core/ContainerFactory.html

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

[7]
http://www.eclipse.org/ecf/presentations/eclipsecon2008/long talk134/ecf_eclipsecon2008_134.pdf

[8] http://wiki.eclipse.org/ECF_API_Docs

[9]
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/tes ts/?root=Technology_Project

[10]
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/exa mples/plugins/?root=Technology_Project
Previous Topic:Reminder: ECF conference call Tues, April 8, 2008 1930 UTC (12:30pm pacific)
Next Topic:Google SOC 2008 Proposal Deadline
Goto Forum:
  


Current Time: Mon Apr 21 03:21:22 EDT 2014

Powered by FUDForum. Page generated in 0.02990 seconds