Pierre van Rooden wrote: > > ADMIN/APPLICATIONS > either move to 'Admin' or 'Applications' application, or keep in core > but deprecate and remove/replace once Apps2 works > Suggestion: keep in core
Agreed. > MMAPPTOOL: > either move to 'MMAppTool' application, or remove > Suggestion: remove Agreed. > CACHE : > either move to 'Cache' application, or remove > Suggestion: remove > CONFIG : > either move to 'Config' application, or remove > Suggestion: remove Agreed. I would not move these to own applications. Who would install those? I would either remove, or perhaps move inside mmbase.jar (if this config 'functionality' is considered useful, it should at least not be in org.mmbase.config, becasue that suggests that it is something which it is not). > MAIL : > either move to 'Email' application, move to the 'Tools' app, or remove > (use 'email' app instead). > Note: SendMailInterface should probably be moved to Tools. > Suggestion: move to Tools > - module/AbstractSendMail.java > - module/builders/EmailSendProbe.java > - module/builders/Email.java > - module/builders/EmailQueueProbe.java > - module/JMSendMail.java > - module/SendMail.java > - module/SendMailInterface.java > - util/Mail.java I'm not sure. I'd say the most stuff (the builders and util/Mail.java) can simply be removed because obsoleted by the email-app. But I think it may be useful to have the SendMailInterface and its implementations still in mmbase.jar, because that could simplify dependency issues. The current email-applications (which is not about sending email an sich, but about the email builder) could use and/or extend on this interface and implementations. Mailing is something which you may want to do in a lot of applications, and the one interface with 2 implementations are hardly bloating mmbase.jar itself. > > TOOLS : > move to 'Tools' application, or remove but keep parts in core or a > separate app (i.e. Jumpers) > Suggestion: move to Tools > - module/builders/AnnotRel.java > - module/builders/Jumpers.java > - servlet/JumpersFilter.java > - module/builders/MMEvents.java > - module/builders/MMEventsProbe.java > - module/builders/PosRel.java > - module/XSLConvert.java > - util/RelativeTime.java > - util/NodeComparator.java These are very unrelated things, that you can as well call it 'misc'... I think that something like NodeComparator which seems to be intended as a tool, but obviously at least is very related to MMBase could as well remain in mmbase.jar. Otherwise you might end up with a dependency on this package only because of such a generic functionality. > VWMS : > move to 'VWMs' application, move to Tools app, keep in core, or remove > Suggestion: move to Tools I think I'd prefer moving to a vwm's application, There is reference from MMBase.java though, so some reviewing of code must be done, to remove that. > - module/builders/vwms/PerformProbe.java > - module/builders/vwms/Vwm.java > - module/builders/vwms/VwmCallBackInterface.java > - module/builders/vwms/VwmInterface.java > - module/builders/vwms/VwmProbe.java > - module/builders/vwms/VwmProbeInterface.java > - module/builders/Vwms.java > - module/builders/Vwmtasks.java > - util/Execute.java > Generally, I think we should not go over the top by moving things out of mmbase.jar. Things which are of very general use should simply remain in it. E.g. I think a 'Tools' application may perhaps not even be worth the trouble because you may end up needing it always, and only gain the hassle of defining the dependency all over the place. I wouldn't mind if traditional and widely used MMBase features like jumpers, posrel and mmevents simply remain in 'mmbase core'. Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
