On Thu, 2002-03-21 at 16:45, Paul Hammant wrote: > Shawn, > > >>If you can port the SF one then good. If you can convince the SF team > >>to migrate to Phoenix or be compatible with (dual mode), then better. > >> > > > >I had some email with the maintainer back in January when I was first > >investigating Telnet needs. > > > >Umm. What is "dual mode"? > > > Peple are resistant to Phoenix. It is possible to The maintaner to > split his/her telnet server into three components: > > 1) An interface ( more later ) > 2) An implementation of that interface. This is a standard bean (public > empty constructor) > 3) A seperate class that is mainable and instantiates (2) and decorates > it with configuration using methods in (2) >
> For us, when we reuse the server a a block, we have out own Block impl > class uinat implements (1), it also instantiates the bean (2) and > decorates it with configuration from Configurable. Thus the user of the > block from within phoenix does not know that the real impl is hidden. > In an ideal world you'd get the maintainer to "open" the socket > listening such that ConnectionManager could be used. I have done exactly > this with the transport.publishing package in cornerstone. > > Dual mode basicaly mean the same codebase canlaunched via main and in > phoenix as a block. > Sounds good. What I'm thinking is: a) reusable I/O TELNET classes for server-side (what I really need) b) Avalon-based framework "core" c) Phoenix block d) non-Phoenix Java main (as you're suggesting) The actual command processing will be pluggable, so it can be Beanshell, Reflection-based, bash, etc. The telnetd design has the concept of a Shell interface. > > -- -Shawn Boyce QCOM, Inc. http://www.qcominc.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
