Jerome Velociter wrote:
Hey,
Yesterday, Vincent introduced a "Modules" section on code.xwiki.org to host XWiki components documentation. From that we had a conversation on IRC about terminology of categories on code.xwiki.org. My observation was that we have some applications that are not really such since they do not offer features to users, but only to developers. Take the date picker application (http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication) : it is not self-standing, this is just for developers that needs a date picker in their apps. I proposed we add an "Extensions" category that would host Skin eXtensions (JSX and SSX) and applications such as the datepicker would fit in there. But as Vincent remarked, we already have an extension category for "an application or script that integrates or interacts with XWiki". In the end, I'll come here with Vincent's idea of merging such extensions with plugins, and then have the following categories :
* Plugins: A plugin is everything that brings new functionality to the wiki, but that does not necessarily expose it to end users. There will be two main kinds of plugins: Front-end plugins (that will mostly come under the form of SX), as the date picker will be for example, and Back-end plugins, which can be of various form, such as an old fashioned xwiki plugin (grand'ma style), or a xwiki component with a velocity bridge, etc. To sum up, plugins bring *functionalities to developers*.
* Applications: An application will stay what it is today : something an administrator can install on its wiki and that provides functionality to end-users, directly visible/exploitable without the need of more programming. This mean a SX that do such is an application, for instance this is how the Ratings application (http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-ratings/) is made. To sum up, applications bring *functionalities to the end users*.
Conclusions: Skin eXtensions will remain only a technical term to designate what they are as platform feature. This is for us, the knowledgeable gurus ; on code.xwiki.org we will offer only plugins and applications.
As for icons to represent those two ideas (both on code.xwiki.org and in the future in XE) - since this is what matters in the end, icons :) - I propose we use application.gif for Applications and plugin.gif for Plugins from the silk set. Pretty straightforward, eh ;)
WDYT ?
From a user perspective, having less names and categories is good. However, given that so many different types of things will go under "plugins", it will be more confusing IMO. There's a huge difference between a calendar sx and a kerberos auth class, or the SVG plugin, or the localization component. Another name I've been suggesting for a while for interface extensions that add new components is, well, "UI components". And another thing I just noticed: we provide GIFs?! GIFs are evil. GIFs are deprecated. GIFs are very limited. It's true that the Burn All Gifs campaign was started a very long time ago, but it is still valid. http://burnallgifs.org/archives/ -- Sergiu Dumitriu http://purl.org/net/sergiu/