On Wed, Jun 25, 2008 at 9:08 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi all, > > Thanks for summarizing this up here. > > I agree to have the shell-telnetd glue at Felix and I am equally open and > share the same concerns with respect to telnetd.
Same here. > I think this may best be answered by Dieter. I agree. regards, Karl > Regards > Felix > > Richard S. Hall schrieb: >> >> Hey everyone, >> >> 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). >> >> 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 >> > -- Karl Pauls [EMAIL PROTECTED]
