Loading...
 
About modularity in Tiki

Modularity

Some other systems like Drupal, Joomla! and WordPress have a small "core" and you add functionality through some of the thousands of modules/extensions/plugins/add-ons. On the other hand, in Tiki, pretty much all the functionality is offered in the "core". Please read about the Tiki model. There is a mods system for functionality outside the core but it is the exception (mods are for rarely used things).

A recurring concern about Tiki is the perceived lack of modularity. But should you be concerned?

There are various schools of thought about modularity. It is not a silver bullet.

In later discussions Torvalds explained the reasons for its choice: a fully modular architecture, like the one adopted for HURD, would have posed problems to a degree of complexity that it could have compromised the accomplishment of the project. To avoid such risks and keep the degree of complexity of the project as low as possible, Torvalds decided to design a monolith and he actually wrote all the architectural specs himself, avoiding all the problems related to collective projects (e.g. division of labor, coordination, communication). On the other hand, the HURD micro–kernel, a project in direct competition with the Linux kernel, has paid for the choice of pursuing a fully modular approach from the beginning in terms of the continuous delays that have plagued its development. Nowadays, it is still under active development and still lacks the stability and performance assured by the Linux kernel.


Source: Modular Design and the Development of Complex Artifacts: Lessons from Free/Open Source Software (2005) by A. Narduzzo & A. Rossi

As a result, the act of decomposing a large software project into components is an activity that results, at its best, in a suboptimal outcome: some sources of interdependencies are well determined and taken into account in the design of components and interfaces, while others are not. In some sense, even careful decomposition of large software projects tends to be accomplished making trade–offs between sources of interdependencies, recognizing the more visible ones and disregarding the less evident or less important ones. These reasons, combined with the huge size of large software project, account for the difficulties in the subsequent integration – testing – assembly phases. Likewise, less careful decomposition results in even greater problems at the final stages of code integration.

Source: Modular Design and the Development of Complex Artifacts: Lessons from Free/Open Source Software (2003) (which has more info than the 2005 paper: 39 pages vs 10 pages) by Alessandro Narduzzo and Alessandro Rossi

"There is, by and large, only one code base at Google. This has many advantages. Most obvious is that it is really easy to look at and contribute to code in other projects without having to talk to anyone, get special permissions or fill out forms in triplicate. That is just the tip of the iceberg, though. Having one codebase means that there is a very high degree of code sharing."

Source:
http://www.manageability.org/blog/stuff/google-coding-cultures

Gregor J. Rothfuss wrote:
"You can still enforce good interfaces but seeing which code you are about to break with a single grep is really useful"


Banon comes from a distributed systems background and says you want to run the compute next to the data. All the compute too; not search in one place, BI in another, machine learning in a third. You should do it in a single system.

Source: http://www.theregister.co.uk/2014/12/23/elasticsearch_big_data_search_tool_fancy_an_elk_hunt/?page=2

Modularity should not be a goal in itself.

The goals are:

  • Code re-use to avoid duplication and provide easier maintenance and more functionality
  • Better performance (ex.: only load what you need in memory)
  • Consistency (to be able to change the look & feel or behavior throughout the application)
  • Make it easier for devs to learn the system, and add/extend functionality without having to understand the whole system
  • Make it easier for developers to work on various parts of the system without interfering with others
  • Make it easier to test
  • Security
  • Maintainability
  • Upgradeability
  • Adaptability
  • Coping with complexity
  • Reduce disk space
  • etc



Sometimes, too much modularity can cause that there is in fact more code duplication. When you have 3000 third party add-ons, there will be duplicate functionality because developers won't know everything that is available in the other 3000 add-ons. And even if they know, they may not want to re-use the code from the other module and have it as a dependency.

For a developer, modularity is great when what you need to do so happens to be planned that way. But what about if you want to change a behavior that was not planned that way? You may end having to change a lot of the core code anyway.

http://en.wikipedia.org/wiki/Intertwingularity

So, as with many things, while putting everything in black or white would be reassuring and simple, the reality is that there are many shades of grey and it's important find the delicate balance. The answer to the question is "it depends".

Is Tiki modular from
a coding point of view? Pretty much (depends where) and it evolves over time as code is refactored. Tiki has community coding in mind. Please read Hello World (Introduction)
a Tiki admin point of view Yes. All the features can be turned on or off. And you can use and participate to http://profiles.tiki.org, which are collections of settings.
a packaging point of view No. This is a choice. Many web apps will make you download a "core" which offers basic functionality. And then, you must download modules/extension/plugins/add-ons/languages separately. In Tiki, it's all in one nice package and you decide what you activate. More on this topic: The Tiki model




See also: Coping with Complexity


Contributors to this page: Marc Laporte .
Page last modified on Monday 15 April, 2019 23:06:18 GMT-0000 by Marc Laporte.

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Group
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend, alert + Social Bookmarking
Terms and Conditions
Theme
TikiTests
Timesheet
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools