>>> 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.
