Loading...
 
The Kerrnel's Musings on a Proposed Framework for Mods. Type of page »  Projects

TKM Proposed Framework: Mods

TKM Proposed Framework
-
Image

MODS

Target: TikiWiki 4.0

(The term "mods" in this discussion refers to the mods that are "after-installation" files to extend Tiki, not to the modules that display in the left and right side columns.)

Preamble

The mods aspect of TikiWiki has long been a graveyard for old or even unused features that are seen as "taking up space". My opinion, supported by others, is that one of the main reasons for this is that mods tend to be quite difficult to maintain and support outside of the Tiki core. If you wanted to write a mods for a specific task that the majority of people probably wouldn't use, then you will find that it is a daunting and difficult process. It is easier to write something into the core of Tiki than it is to create a mods. The flip side of this is that by incorporating a minor feature into the core makes it a headache for the core developers to maintain as Tiki changes, and eventually gets put out to pasture in the mods area.

It is a specific skillset required at the moment, to be able to decipher and write mods. Part of ths is lack of documentation. Furthermore, there is no real way of maintaining mods, for keeping them up to date, or for proper distribution from third-parties. Do we really want to maintain a separate tree for mods, or just bundle a couple of core ones that interface with social networking sites, and leave the rest to the end-users to maintain as they require them?

Many projects these days in the open source world are made to be extremely modular, one reason is for customizability, but another is because the developers working on the core of the project do not want the burden of having to update all of those mods as part of normal development efforts if they were to actually be a part of the core distribution. I think Tiki has gone the right direction for what we need by incorporating so many key and useful features into its main code base, but I do think that there is room for those mods from people who may wish to do something that not everybody else does. This puts the burden on the author or the mods, and those who use it, to keep it updated. It gives Tiki additional functionality to more people, without the burden of the core developers having to keep it up to date.

My proposal is for a revamped mods framework that would make it a lot easier for users to contribute to the growth of Tiki, while allowing the core development teams to continue its development. Along with this framework would include a central distribution model using a Tiki site running, of all things, a mods mods that allows users to actually upload their mods components and have them packaged in a standard distribution format. Minor changes will need to be made to TikiWiki to accommodate this new model, but I think the benefits are enormous. Given the amount of work needed on this, I would target version 4.0 for its full incorporation.

API Building Blocks

I will introduce some concepts here that others have probably discussed over time, maybe with different terminology. The key thing to understand though is that when working with modularity, you have to have a common way of doing things. When working in the core, some of these things are already available to you, but then you also have tight integration. mods are not meant for tight integration, they are meant to fulfill a given task, and with some exceptions, are more for read-only functionality given certain input.

Security is also a main component, some of which will be addressed by how Tiki references the mods, and some will be taken care of within the mods with a per-mods permission system. As API's go, functions will need to be made available that will allow general access to many (not all) of Tiki's major libraries (such as lib/trackers/ and lib/forums), so mods developers don't need to go hunting around for functions. Code bloat will be addressed in the API Defined section, so those worried about adding 10k lines of code for a 100 line mods need not fear.

Prototyping

Data sharing between Tiki and mods is very important. It is important that things are presented in an organized way so that the mods developers can write their mods more or less autonomously without having to come to the devs for help. Part of the way that code bloat and compartmentalization of information is proposed to be handled is through prototyping.

Simply put, prototyping is a bundling of existing Tiki information into a compartmentalized structure. For example, a User prototype is one which incorporates a data structure containing information on the user who is trying to access the mods: user name, groups, permissions. It would also incorporate user information functions in this prototype, whether individually or as part of libraries. I see this presented as its own class structure with includes for the libraries specific to the user functions.

Another example is a tracker prototype that incorporates top-level tracker information within its own data structure, this includes tracker ids, names, number of entries, permissions, admin options. Incorporated with this would also be the tracker code library (or a subset...this should be discussed) and its functions. Bundle this up as a class.

This can be done for any other major feature, like Forums, or the Calendar, anything. This prototyping will later allow the developer to specify in the mods configuration what prototypes they will need, to make for more efficient bundling of code. Depending on the direction we agree to take, it may mean that we have to look at our current libraries and split some of them up, depending on what we want to make immediately available to the mods API.

Security

Security is a three-pronged approach. When Tiki references the mods, the mods is only really accessible if you have the permission to access the mods. Add to this the security restrictions based on mods permissions as set by the developer and site administrators, and it's pretty tight. A third access check should also be incorporated within the API itself as it pertains to the prototypes.

First, as the API is referenced, it builds itself based on the prototypes. As each prototype is built, it verifies that the user running the mods has access to the components of the prototype. If they don't have access to trackers, then trackers won't get prototyped, and an error will be sent back for the developer to program in how to handle that. If they do have access, then as data is incorporated into the data structure, some of it is immediately vetted. "Does the user have access to file galleries? - yes... Does the user have access to this file gallery? - no...so don't include that data."

Prototypes, at this point, are planned to be included in a file in the mods package. To be determined.

Please note that this does not preclude the more adventurous or advanced mods developer from directly referencing Tiki libraries from their own source. The prototyping is there to make writing the mods easier.

mods Permissions

Each mods a mods developer creates, can also have its own mods permissions. Based on the name of the mods, they can create a preference tag. For example, they create a tag called admin, or write or forums, presumably there is an admin section to the mods, or it allows you to commit data to something, or for some reason they may not want you to access forums from the mods, even if you have access to them. So their mods is called "Facebook Mod" or something. So a new permission tag is created: "mod-facebook-mod-admin" or "mod-facebook-mod-write", etc.

Now the third prong of permissions is in place.

API Defined

mods Class

Requires and Includes

Applying the Prototypes

mods Plugins

Depending on the function of the mods, you may wish to incorporate some of its use or data into a Wiki page. Rather than plugins being bundled up with all the other plugins distributed by Tiki, these plugins will get stored in the same area as the mods and get a name that identifies them as a mods plugin. Something like {MOD-mods-NAME-PLUGIN()}.

This keeps things clean. If a user wants to remove a mods from their system, the plugin (which only works with it) goes too.

mods Templates

Similar to the plugins, specific templates for a mods will get bundled with it. Tiki will need to know it is a mods template so it knows where to look for it. Likewise, this makes it easier to install and remove mods entirely.

Package Structure

The package structure is a couple of directories and files, some automatically generated by the packaging process proposed below, but some created by the developer. Proposed is...

/tikiroot/mods/
   -> mods-name/
      -> README           (notes from the developer, including licensing, copyright)
         index.mod        (auto-generated from packager, includes md5 and manifest)
         index.php        (redirect)
         prototypes.mod   (list of prototypes)
         settings.mod     (list of permissions and some default values)
         mods.php       (main mods script)
         other.php        (any number of other support scripts/libraries the user wishes to use)
         plugins/         (directory for any mods-specific plugins)
         templates/       (directory for any mods-specific templates)


This is the baseline definition. The user may have additional scripts to support the main one, which would be included within the same mods-name directory.

Self-Contained

The idea for self-containment of the mods within a particular hierarchy, is to make installation and removal easier. The more complicated installs get, and the more files need to get distributed around into various directories, it not only makes removal difficult, but it also makes troubleshooting a headache. If everythign is contained in one place, then the only complexity is getting Tiki to recognize where to go. If it's the same all the time, then this shouldn't be too hard a task.

The mods mods (Dogfood+)

Here comes some irony. Or simile. (I can't remember, Alannis Morisette messed it all up...) Adding to the chicken or the egg debate, in order to facilitate standard packaging and centralized distribution, I propose that mods.tiki.org run a full Tiki install, and make use of a mods called mods (or somesuch). Essentially, this mods mods is itself dogfooding this new framework.

Let's be honest, adding a mods for packaging and distribution of something - anything - is generally not considered a core feature of TikiWiki. Nor should it be, since there may be a handful of sites that would make use of it. Just because we need a feature like that doesn't mean it should work its way into the core, so we make it a mods.

This mods would conceivably allow users a central repository for all Tiki mods (similar to themes.tiki.org...and come to think of it, that could be the second mods!). Here's how it works...

Package Generation

Developers of a mods would go to the mods site with their script all tested and working. So they login to the site and access the submit new mods area. They upload via a form all of the files they have. The form has them specify the prototypes used, has them add a blurb about the mods, what it's for, etc., has them specify a list of users authorized to make updates (anybody, them, or them and some others) and then proceeds to do md5 checks on the files, zips them up in a standard zip format, generates the index.mod file, adds a licensing file, whatever, and then sticks the zip in a file gallery. At the same time, it adds an entry to a tracker that tracks the distros.

Package Distribution

From a wiki page, anybody browsing the site can immediately see a fancy list of all the mods out there (themes, anyone?). The mods will keep one version behind for each package it builds, so it has a recent and previous copy. Anything else gets deleted as new versions are sent up. We've done MD5 checks on everything and created a manifest, so we also have a trusted source for everything.

Package Installation

Tiki would need to be modified a little, but going to an install option will allow you to either browse mods.tiki.org, or specify another site running a mods mods, or specify a package file. You can plugin a URL referencing the mods, either as a wiki page or tracker (to be determined) and the install feature will display details for the mods, or allow you to click on a button to automatically download the mods and install it.

The install would break out the mods contents, verify md5, install the mods to the mods directory, and install the new mods permissions. Then it would take you to the mods page of the site so you can make use of it.

Conclusion

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
Diagram
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw -superseded by Diagram
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Gantt
Group
Groupmail
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Kanban
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
Terms and Conditions
Theme
TikiTests
Federated Timesheets
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