Matthew Toseland wrote: > On Thursday 22 January 2009 10:43, Florent Daigniere wrote: >>>>> FMS is not non-fixable. You just don't care about it. >>>> We don't bundle jSite, Thaw or Thingamablog either, even though they are >>>> written in Java. Because they are separate, non-integrated, standalone >>>> applications that we don't have control over and don't have the resources > to >>>> review. FMS could conceivably be somewhat less separate in that FMS could >>>> link to the freenet web interface and vice versa, but given that we have >>>> Freetalk, which is integrated properly and has a better architecture, why >>>> bother? >>> Depends on what "architecture" means. >>> If you means the message format -- maybe. >>> If you means the class structure, program flow, etc -- it's not. >>> >>> This can be very subjective -- you may ask nextgen to see if he agree. >>> >>> The code problems I known in FMS is local -- just change one or two >>> line in a function. >>> The code problems I known in FreeTalk/WoT involve refactoring. >>> In this sense, I consider FMS more maintainable. >> My guess is that by architecture toad means "separation in between WoT >> and Freetalk". I do agree with him that fms's approach (one WoT >> per-application) is not the way to go. >> >> Regarding Somedude's reactivity/responsivity, I do have a different >> experience: I sent two patches to him through the FMS board, none of >> them got applied... And at least one of them (a trivial patch fixing the >> build process on macos) should have been without any further discussion. >> >> Regarding Freetalk itself, well I haven't reviewed the code yet so I >> won't comment. From what I have seen (some shared classes ended in the >> node's package!) it's a mess. > > What's wrong with putting shared classes in the node? It seems the most > practical solution right now? >
It's ugly design-wise, it's silly to keep (apparently) unused classes around, ... Long term solution is plugin-dependencies... But I have already made a case for them iirc.
