Tags:
create new tag
, view all tags
One of my goals in DakarRelease was to trim a lot of fat from the TWiki core. I've been successful in some areas (moving skins into contribs, for example) but there's still a lot of fat left. Here are some more love-handles that TWiki could afford to lose from its waist during EdinburghRelease. I'm not suggesting they are dropped, just moved into a contrib so an end user can make a decision whether that module is needed or not in their environment:
  1. Fat default templates - we already discussed this one, the default templates are based on ClassicSkin so they are far too flabby, and need trimming down to a themeable set of basic CSS-based templates
  2. Access Control. One role for TWiki is as a PIM (personal information manager). This role has no need for permissions checking, access controls, registration etc. etc.
  3. I18N. Yes, I know we only just added it to the core; but hey, I only use English....
  4. Compatibility code. I have no interest in it; I upgrade topics once, and once only, when a new version is installed. Pure cellulite.

Any other candidates?

-- CrawfordCurrie - 08 Jan 2006

Note before editing this topic, please do 10 sit-ups. It may not improve your contribution, but it will cut into those Christmas calories! wink


From my own experience I fully agree on the templates. The other parts are, however, not so clear for me:

  • I'm optimistic that it is possible to technically isolate most security related functions. We have to keep in mind that security has to be "designed in", so every core (or plugin) enhancement would have to be checked for security relevant parts. There'll be a lot of dependencies between core and a security plugin.
  • I don't think that I18N should be removed from the core. I'd rather opt for extending the framework for string generation so that plugin templates and user topics can be internationalized, too (but IIRC this is on the roadmap anyway).
    1. All micro-kernel-like designs fail miserably if different plugins start to interact with each other because every new plugin adds dependencies. I18N in particular is a feature with which every plugin should be able to interact without having to check whether I18N is installed.
    2. Starting with I18N may be tedious, but having I18N available is a great asset. If it would be dubbed an "optional extension" then I'm afraid that the motivation for authors to write %MAKETEXT% for every string will drop even more.
  • In my opinion, removing compatibility code is almost always a bad idea because it creates a mental obstacle for upgrading to a new TWiki release.

-- HaraldJoerg - 09 Jan 2006

CategoryFightTheFlab

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2006-01-16 - CrawfordCurrie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.