Easily find issues by searching: #<Issue ID>
Example: #1832
Easily find members by searching in: <username>, <first name> and <last name>.
Example: Search smith, will return results smith and adamsmith
1.1.6 - 04th March 2011
Changes since the last delivery:
* Fixed some bug encountered when using vi editor and resizing the window;
* Refactored SshTerminalPanel into SshTerminalWrapper to unify delivered library features
with the ones required for integrating the SSH Terminal in ADS. This way we avoid
source-code duplication and confusion when bugs are found in the SSH Terminal integrated
in ADS and debugging is required. Also, we have some unit-tests that use the
SshTerminalWrapper combined with vttest to check that the GUI is functional and there
are no regressions. In order to use this wrapper you have to:
o create a new SshTerminalWrapper instance and retrieve the GUI component using
o start authentication using the SshTerminalWrapper.start() method;
o in order to deal with Terminal's GUI settings you should implement the SSHOptions
interface provided in the API and use the SshTerminalWrapper.applyOptions() method;
Few more notes:
* the lib.terminalemulator's Term class is intended to be private as tampering with it can
cause abnormal behavior on the terminal emulator;
* the SshConnectionFactory class is provided in the API as an entry point for creating
sessions, setting the known hosts file or using custom host key repository. Also, there
is no need to create one JSch instance for each SSH session as the global configuration
is the same. See the README file for more info.
Did you take a look at the new SshTerminalWrapper? It has most of the ssh connection setup and in the next build we'll include the remaining stuff from TermAuth, FindBarVT100 and the selection methods from VT100TerminalPanel.
--emi
On Mon, Mar 7, 2011 at 6:09 PM, Andy Goryachev <andygoryachev@aquafold.com> wrote:
Hi Emilian,
The reasons for VT100TerminalPanel existence were twofold:
1. there were bugs in the original thread implementation
2. the original code was too opaque (meaning we can't easily access its components to augment/change the functionality) and incompatible with our logging/i18n/options frameworks.
Also, there was a lack of coordination between developers as to how much development is still needed: I've been told that the terminal code is complete and all that's left was to integrate it.
So, seeing how this is not the case, and the development of the terminal core code is still continuing, I suggest we determine a way to structure our work which will result in a seamless integration rather than in two diverging branches.
Of course, we all understand that it might be more difficult to achieve in Aquafold environment in comparison to an open source environment. So let's be extra careful in partitioning the APIs.
Let's start with saying that most of the terminal code as it exists now seems to work. The threading, menus, logging are integrated, as well as implementation of some requirements that appeared later, such as paste on a mouse right-click. What we need to do now is to refactor both sides so you can run the terminal within your Ssh* components (that we don't use) and we could continue using our menu, logging, and custom functions. One possible way to achieve that is to carefully move some core functionality away from VT100TerminalPanel (I attached the latest copy of it and its parent component for you to see) into the core terminal code - more specifically, the threading, some of the listeners, and Action's. Please let me know if you have other ideas, as we need to coordinate the effort. Let's discuss them individually in a separate message.
Keep in mind that we can not use your SshTerminalPanel class. I would rather not merge the changes that you put into that class, as each change has to be analyzed and manually merged into our code. In fact, I would suggest to move it to a com.common.terminal.test package, along with other tests, if you have any (Niels, should we add a separate package in our test.* hierarchy for the terminal tests?).
In conclusion, I suggest we take a look at the VT100TerminalPanel class, identify pieces that don't belong there but rather belong to the core terminal and move them. At the same time, if there is a bug fix or a new functionality that you put in SshTerminalPanel and which should be in the final product, we either move it to the core terminal code, or extract as a class/interface which Aquafold can use (subclass or implement).
How does that sound?
-a
On Fri, Mar 4, 2011 at 8:28 PM, Niels Gron <nielsgron@aquafold.com <mailto:nielsgron@aquafold.com>>
wrote:
Hi Emilian,
I am hoping that you and Andy can discuss an interface for the SSH Terminal that integrates well
with Aqua Data Studio. I am not sure if the current change is sufficient. Once you guys agree
on an interface then we should be able to have a drop-in deliverable.
Also, moving forward, can you cc Andy on the SSH Terminal builds? He will do integration of the
SSH Terminal from now on.
thanks
-Niels
Hi Emilian,
Are you saying we should use SshTerminalWrapper instead of Term? (Why is it called a wrapper?)
If so, Niels will have to pay for integration again.
A cursory review tells me that I can't access Term instance (please add a public accessor), and I can't change Term properties (like setBackground) individually - not that we do, but why invent a new entity SshOptions (they have nothing to do with SSH, by the way), and remove a useful functionality? I suggest you get rid of it.
Also, please get rid of 'private' and 'final' qualifiers in your code, unless you have a VERY good reason to. What if we want to change the way Session is created?
Thanks!
-a
Hi Emilian,
Are you saying we should use SshTerminalWrapper instead of Term? (Why is it called a wrapper?)
If so, Niels will have to pay for integration again.
A cursory review tells me that I can't access Term instance (please add a public accessor), and I can't change Term properties (like setBackground) individually - not that we do, but why invent a new entity SshOptions (they have nothing to do with SSH, by the way), and remove a useful functionality? I suggest you get rid of it.
Also, please get rid of 'private' and 'final' qualifiers in your code, unless you have a VERY good reason to. What if we want to change the way Session is created?
Thanks!
-a
integrated version 1.2.2
most of the functionality is shifted to Emilian's code now, which should make subsequent merges much easier.
integrated version 1.2.2
most of the functionality is shifted to Emilian's code now, which should make subsequent merges much easier.
Issue #5326 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| No fixed build |
| No time estimate |
Did you take a look at the new SshTerminalWrapper? It has most of the ssh connection setup and in the next build we'll include the remaining stuff from TermAuth, FindBarVT100 and the selection methods from VT100TerminalPanel.
--emi
On Mon, Mar 7, 2011 at 6:09 PM, Andy Goryachev <andygoryachev@aquafold.com> wrote:
Hi Emilian,
The reasons for VT100TerminalPanel existence were twofold:
1. there were bugs in the original thread implementation
2. the original code was too opaque (meaning we can't easily access its components to augment/change the functionality) and incompatible with our logging/i18n/options frameworks.
Also, there was a lack of coordination between developers as to how much development is still needed: I've been told that the terminal code is complete and all that's left was to integrate it.
So, seeing how this is not the case, and the development of the terminal core code is still continuing, I suggest we determine a way to structure our work which will result in a seamless integration rather than in two diverging branches.
Of course, we all understand that it might be more difficult to achieve in Aquafold environment in comparison to an open source environment. So let's be extra careful in partitioning the APIs.
Let's start with saying that most of the terminal code as it exists now seems to work. The threading, menus, logging are integrated, as well as implementation of some requirements that appeared later, such as paste on a mouse right-click. What we need to do now is to refactor both sides so you can run the terminal within your Ssh* components (that we don't use) and we could continue using our menu, logging, and custom functions. One possible way to achieve that is to carefully move some core functionality away from VT100TerminalPanel (I attached the latest copy of it and its parent component for you to see) into the core terminal code - more specifically, the threading, some of the listeners, and Action's. Please let me know if you have other ideas, as we need to coordinate the effort. Let's discuss them individually in a separate message.
Keep in mind that we can not use your SshTerminalPanel class. I would rather not merge the changes that you put into that class, as each change has to be analyzed and manually merged into our code. In fact, I would suggest to move it to a com.common.terminal.test package, along with other tests, if you have any (Niels, should we add a separate package in our test.* hierarchy for the terminal tests?).
In conclusion, I suggest we take a look at the VT100TerminalPanel class, identify pieces that don't belong there but rather belong to the core terminal and move them. At the same time, if there is a bug fix or a new functionality that you put in SshTerminalPanel and which should be in the final product, we either move it to the core terminal code, or extract as a class/interface which Aquafold can use (subclass or implement).
How does that sound?
-a
On 3/6/2011 11:06 PM, Emilian Bold wrote:
a clear entry point for your needs.
Using Term or other classes directly means that the API isn't providing what you need and that
should result in a bugreport not a workaround on your part :-)
I guess we need to define what must VT100 do and what remains for your client code to do. Then we'll
also know more clearly for example where does a bug reside and if VT100 just has a front-facing API
we'll be able to change everything underneath without worrying we might break client code.
So, how does the latest API look like? Are they any other changes needed?
--emi
On Fri, Mar 4, 2011 at 8:28 PM, Niels Gron <nielsgron@aquafold.com <mailto:nielsgron@aquafold.com>>
wrote:
Hi Emilian,
I am hoping that you and Andy can discuss an interface for the SSH Terminal that integrates well
with Aqua Data Studio. I am not sure if the current change is sufficient. Once you guys agree
on an interface then we should be able to have a drop-in deliverable.
Also, moving forward, can you cc Andy on the SSH Terminal builds? He will do integration of the
SSH Terminal from now on.
thanks
-Niels