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/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
