felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dieter Wimberger <die...@wimpi.net>
Subject Re: telnetd discussion
Date Wed, 25 Jun 2008 20:30:36 GMT
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 for  
an occasional, simple telnet based remote access to the felix shell  

If this is correct, then I wonder whether it really requires a telnet/ 
SSH2 compliant server with connection management to achieve this.  
Actually, taking equinox as an example, it's nothing more than a  
simple single connection without any telnet protocol negotiation  
happening at all.

So, this is the question I'd suggest to ask yourselves before we  
proceed to find a solution:
Do you need something like the simple equinox "telnet" access, or do  
you need a "real" telnet/SSH server?

If the answer is "we need a simple access", then I would actually  
suggest to hack a simple listener implementation into the glue bundle,  
make it "the telnet" bundle and go with it (from my point of view,  
telnetd-osgi would be simply an overkill tool for that job).


> The following is intended as a summary of the recent discussion on  
> telnetd (most of this analysis is from an email Felix Meschberger  
> sent me).

Felix, could you please drop me a copy of this analysis? :)

> The following bundles are necessary for remote shell access to 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 commons  
> bundle, but we could easily package this into the telnetd bundle so  
> that it is self-contained (we can help make this happen with the  
> maven bundle plugin).
> From Felix' analysis, we could simplify creating remote shell access  
> by having the glue bundle inject a dummy configuration into  
> telnetd's ManagedServiceFactory so that the Config Admin dependency  
> could be optional. This all sounds good. (We could even consider  
> embedding the telnetd stuff directly into the glue bundle, but that  
> is another discussion.)
> Given this setup, we can ponder where should the telnetd and glue  
> bundle projects reside? The obvious choices are at the Source Forge  
> telnetd site or at Felix. I think that any combination can be  
> reasonably argued. Here is my personal take...
> I definitely think it makes sense to create a subproject for the  
> glue bundle at Felix, I am less certain about the telnetd bundle  
> itself. While I definitely want to support the telnetd bundle, I 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  
> implementation that could easily be used outside of OSGi or not? If  
> so, then it seems like it should be separate from Felix. On the  
> other hand, if the implementation is somehow tied to OSGi, then it  
> might make sense to host it at Felix.
> Another possibility is that telnetd is generic, but that it has some  
> sort of wrapper that integrates it into an OSGi environment, then  
> maybe it makes sense to host the wrapper at Felix, keeping the  
> generic library at SF.
> I would definitely like to see this functionality available. My mind  
> is open as to how to achieve it, so what does everyone else think?
> -> richard

View raw message