Paul Hammant wrote:
I am fairly sure this can go. I've looked into it before.This is good news!
My immediate feeling is that we should not do anything suddenly concerning FTP. Instead - at least what's circulating in my mind - is to take care of the underlying components first. As you known there is already independent component builds for some of the blocks in Cornerstone - but this probably needs some more restructuring. The independent block builds are largely driven by the James dependencies. The FTP app introduces additional dependencies that we should perhaps address as part of the release plan. If we can get to a point where we have the FTP app building against release blocks then I would be much more comfortable thinking about a possible home and ensuring that the relationships between the FTP app and cornerstone and well defined and maintainable.
Does this make sense?
I really sorry, but I've read it a couple of times and it does not make a lot of sense.
FtpServer works now. It does use Cornerstone, and will move with Cornerstone if/when Cornerstone gets morphed into a set of smaller jars.
I don't think "if" is in question. Corerstone as a single jar file
is not a manageable proposition. The work with James has already
resulted in the establishment of five or so seperate components. The
release process for these components is schedule to roll in place
following the release of the underling Excalibur components.
The point I was making is that I think that it would be sensible to get the FTP package sorted out and synchronized with corenerstone releases so that wherever it moves to, it moves in manner that is "healthy"and "consistent". I think Noel summarised it well - it's about creating a valuable relationship between the FTP and Avalon after if moves by putting the structure in place before it moves.
It does need to eb less dependant on BlockContext (given
we've chosen that model). I saw that as a no-promemo proposition, with a simple move to the lookup key form, There could be an extension of the block which is shutdown capable if that's needed.
Given we've also chosen to shove stuff out of Avalon to reduce to A-F, demo apps, comps and a few ref containers, it seems entirely appropriate to move this to incubator or other.
We havn't chosen to shove anything anywhere. We have undertaken to rationalize and facilitate migration. I'm focussing here on the rationalization and facilitation aspects.
Rana (and to a lesser extent I) have put a lot of work into this and would love to see it go to a place where it gets more attention. This is really good stuff and should not hide amongst demos.
I don't think I've suggested that it should. In fact I've several good suggestions so far concerning potential destinations. I'll restate - my comments concern getting it ready for migration before migration. Based on everything I know about this package - there is no super-urgent agenda - at least nothing that should get in the way of our making sure that something leaving Avalon does so in good shape.
Hope that clarifies things for you.
Cheeers, Steve.
Regards,
- Paul
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
