Is there any particular reason why not to move them out of the kit? I suppose that this is because it would take quite some efforts to extract and abstract common functionalities and such?
Personally I think that it depends on the message that we want to send. If we want other people to start writing modules, then everything that is not core DSO should be a separate module with separate sources, as a separate project. Doing this will also make the module system and our API itself more robust, as we'll start using it for more complex use-cases and we'll be exposes ourselves to the problems and oversights early on. Otherwise, the handful of people that might consider writing a module risk hitting these and be discouraged. Just my 2c. On 27 Aug 2007, at 22:34, Steven Harris wrote: > I'm thinking about the config module separation issue. I don't think > we necessarily need to move them out of the source repo. I think we > just need to do a few things: > > 1) Change the kit building to not include them with releases > 2) Restructure so we can have demos, tests and maybe for each one > right next to the module. > > Any thoughts on this? -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
