Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Subject: RE: telnetd discussion
Thread-Topic: telnetd discussion
Thread-Index: AcjXEHQLGnGsfLMcQeqpj7Kums9NNwAiun0xAAABH5w=
MIME-Version: 1.0
From: Craig Phillips <lcphillips@praxiseng.com>
In-Reply-To: <16FD88D7-C114-4ACE-8E0C-1E1D106DB070@wimpi.net>
References: <48629233.2030601@ungoverned.org>
 <2EC265A3-F4BC-4636-BE46-448041C7876C@wimpi.net>
 <4862AC1C.2050506@ungoverned.org>,
 <16FD88D7-C114-4ACE-8E0C-1E1D106DB070@wimpi.net>
To: <dev@felix.apache.org>
Content-Type: multipart/alternative;
	boundary="_5503CEB1-02B4-4819-B5DC-82B9C67525DF_"
Date: Thu, 26 Jun 2008 10:46:15 -0400
Message-ID: <89D178CC-C9F9-4F47-B96C-6BCF0A9BE932@mimectl>

--_5503CEB1-02B4-4819-B5DC-82B9C67525DF_
Content-Type: text/plain; charset="iso-8859-1"; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable

Hi,

Just tried it out... super small and super fast... For the tiny solution, t=
his looks perfect...

Any chance I could see the source? I want to learn!  :)

BTW - I'm working through the tutorial page on the Felix shell service as I=
 want to do other mediums, such as JMS and JMX...

Kind regards, Craig Phillips


From: Dieter Wimberger
Sent: Wed 6/25/2008 6:10 PM
To: dev@felix.apache.org
Subject: Re: telnetd discussion


Richard, all:

Thought I put the "simple access alternative" together so you can =20
decide upon facts not ideas.

http://www.karanet.at/~wimpi/felix/org.apache.felix.telnetconsole.jar

Size is close to 15kB, only dependency is the felix shell service =20
bundle. Port is 6666 by default and may be configured using the system =20
property "osgi.shell.telnet.port".
(No command history, but BS, DEL and Strg-U work).

Regards,
Dieter


On 25 Jun 2008, at 15:35, Richard S. Hall wrote:

> Dieter Wimberger wrote:
>> Richard, all:
>>
>> I'd suggest to first take a step back and ask yourselves a question.
>>
>> As far as I understood from the discussion, you would be looking =20
>> for an occasional, simple telnet based remote access to the felix =20
>> shell service.
>>
>> If this is correct, then I wonder whether it really requires a =20
>> telnet/SSH2 compliant server with connection management to achieve =20
>> this. Actually, taking equinox as an example, it's nothing more =20
>> than a simple single connection without any telnet protocol =20
>> negotiation happening at all.
>>
>> So, this is the question I'd suggest to ask yourselves before we =20
>> proceed to find a solution:
>> Do you need something like the simple equinox "telnet" access, or =20
>> do you need a "real" telnet/SSH server?
>>
>> If the answer is "we need a simple access", then I would actually =20
>> suggest to hack a simple listener implementation into the glue =20
>> bundle, make it "the telnet" bundle and go with it (from my point =20
>> of view, telnetd-osgi would be simply an overkill tool for that job).
>
> Good question. Most of my use cases would be the simple variety, but =20
> I wouldn't want to be constrained to it either. I think the point, =20
> for me, is to create a useful tool that is flexible enough to be =20
> used in simple cases as well as more sophisticated ones.
>
> -> richard
>
>>
>> Regards,
>> Dieter
>>
>>
>>> The following is intended as a summary of the recent discussion on =20
>>> telnetd (most of this analysis is from an email Felix Meschberger =20
>>> sent me).
>>
>> Felix, could you please drop me a copy of this analysis? :)
>>
>>> The following bundles are necessary for remote shell access to =20
>>> Felix:
>>>
>>> 1. Felix' standard shell bundle (i.e., shell bundle).
>>> 2. Dieter's telnetd bundle (i.e., telnetd bundle).
>>> 3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
>>> Dieter also mentioned that the telnetd bundle depended on a =20
>>> commons bundle, but we could easily package this into the telnetd =20
>>> bundle so that it is self-contained (we can help make this happen =20
>>> with the maven bundle plugin).
>>>
>>> From Felix' analysis, we could simplify creating remote shell =20
>>> access by having the glue bundle inject a dummy configuration into =20
>>> telnetd's ManagedServiceFactory so that the Config Admin =20
>>> dependency could be optional. This all sounds good. (We could even =20
>>> consider embedding the telnetd stuff directly into the glue =20
>>> bundle, but that is another discussion.)
>>>
>>> Given this setup, we can ponder where should the telnetd and glue =20
>>> bundle projects reside? The obvious choices are at the Source =20
>>> Forge telnetd site or at Felix. I think that any combination can =20
>>> be reasonably argued. Here is my personal take...
>>>
>>> I definitely think it makes sense to create a subproject for the =20
>>> glue bundle at Felix, I am less certain about the telnetd bundle =20
>>> itself. While I definitely want to support the telnetd bundle, I =20
>>> am not sure if it really falls into the scope of the Felix project.
>>>
>>> I guess the question is, is telnetd a completely generic telnet =20
>>> implementation that could easily be used outside of OSGi or not? =20
>>> If so, then it seems like it should be separate from Felix. On the =20
>>> other hand, if the implementation is somehow tied to OSGi, then it =20
>>> might make sense to host it at Felix.
>>>
>>> Another possibility is that telnetd is generic, but that it has =20
>>> some sort of wrapper that integrates it into an OSGi environment, =20
>>> then maybe it makes sense to host the wrapper at Felix, keeping =20
>>> the generic library at SF.
>>>
>>> I would definitely like to see this functionality available. My =20
>>> mind is open as to how to achieve it, so what does everyone else =20
>>> think?
>>>
>>> -> richard
>>

--_5503CEB1-02B4-4819-B5DC-82B9C67525DF_--