Re: [Ftpserver] Comments on the new code
Paul Hammant wrote: OK, if we're keen about Dependency Injection, we'd need to change a lot. The basic FtpConfig component should have little knowledge of UserManager (and others), and no coupling to it... If we do aim for a DI/IoC approach (and I think we should), should we choose a DI implementation (Pico, Spring...) that we ship as the default implementation? Or, should we try to implement a specialized runtime ourselves? I would certainly go for the former option and would favour Spring but I'm guessing that Paul won't agree on this choice :-). /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Ftpserver] SVN and mailing lists
Noel J. Bergman wrote: Remind me if no one else gets to it first. As I write this note, I'm sitting at LAX, without connectivity. I have no idea when this will actually get posted. Now that it appears that FTPServer has happily come back to life, I would like to see a greater community grow around it. That would be great Noel! I'm not a commiter so if any formal request is needed that would be for Paul or Rana. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Ftpserver] Comments on the new code
Paul Hammant wrote: OK, if we're keen about Dependency Injection, we'd need to change a lot. The basic FtpConfig component should have little knowledge of UserManager (and others), and no coupling to it... If we do aim for a DI/IoC approach (and I think we should), should we choose a DI implementation (Pico, Spring...) that we ship as the default implementation? Or, should we try to implement a specialized runtime ourselves? I would certainly go for the former option and would favour Spring but I'm guessing that Paul won't agree on this choice :-). /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Ftpserver] Comments on the new code
Actually, I think that perhaps we might want to look at OSGi, and supporting FTPserver as an OSGi bundle. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Ftpserver] Comments on the new code
On Sunday 02 October 2005 06:52, Niklas Gustavsson wrote: > Paul Hammant wrote: > > OK, if we're keen about Dependency Injection, we'd need to change a > > lot. The basic FtpConfig component should have little knowledge of > > UserManager (and others), and no coupling to it... > > If we do aim for a DI/IoC approach (and I think we should), should we > choose a DI implementation (Pico, Spring...) that we ship as the default > implementation? Or, should we try to implement a specialized runtime > ourselves? I would certainly go for the former option and would favour > Spring but I'm guessing that Paul won't agree on this choice :-). DI/IoC isn't dependent on a runtime platform, and I think Paul agrees that one can make good DI/IoC without relying on Spring, Pico or whatever. Also, these things tends to take religious proportions fairly quickly, so staying away from any such commitment is a GoodThing. IMHO, the basic design and implementation should be XML free and provide a straight forward API for assembly, configuration (preferably atomic) and the other stuff. Any runtime platform support can be added on top of that. Look at Jetty for an example of this approach. Now, Noel's suggestion for OSGi as the runtime platform is interesting, if for no other reason than it allows for hot deploy and reloads. But I think it would be possible to provide a BundleActivator and register the service(s) even if FtpServer does not require OSGi by definition, if the above approach is done well (again Jetty is an example of OSGi bundle on top of its API). Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
