User:Salvatore Ingala/GSoC 2011 application
- Up to date project notes are being kept on the page /Notes.
Name: Salvatore Ingala
Email: salvatore.ingala -at- gmail.com
Project title: AMICUS: Awesome Monolithic Infrastructure for Customization of User Scripts
Timezone: UTC+2 (Italy)
Typical working hours: Mostly afternoon to evening from Tuesday to Friday until July, flexible any other day and after July.
IRC or IM networks/handle(s): ^Spider^
A better solution would be to have a nice, standardized interface to do user customizations.
End users should have a central place where options for all enabled gadgets/userscripts can be changed in an easy way and with proper validation.
Moreover, the tool developers should not have the bother of writing code to build the configuration interface: they should just expose an object with meta-configuration (option name, data type, default value, description, (possibly) code for validation and so on) and be happy.
AMICUS is the Latin word for "friend". AMICUS wants to be friend with both tool developers and end users! (Advertising – don't bother...)
This would be even interesting for some core components (e.g.: toolbar customization).
I'm a computer science student at University of Catania (Italy); I completed the “Laurea triennale” (roughly equivalent to a bachelor's degree) in 2009 end expect to finish master's degree in 2012.
I'm a sysop on Italian language Wikipedia from 2005.
- An easy-to-use GUI to permit end users to set configurations for all tools that expose a configuration object.
Some points need attention:
- Efficiency: avoid doing useless AJAX calls and minimize useful ones (the idea is to use HTML5 client-side storage to implement a cache for read access; the cache could be an independent module, useful on its own for other applications)
- Graceful degradation: on older browsers, it must fail without breaking anything and just return default configuration values.
- The application interface for configuration metadata should be kept very easy for simple things (most options are very simple, like “true/false” or multiple choices), while giving to the tool writers sufficient control to do more complicated things or customize the configuration GUI.
If time permits
- Application to existing user scripts (Navigation Popups, HotCat. ...)
- Code for toolbar customization should be much easier now than writing it from scratch.
- Pushing for deployment on Wikimedia wikis.
- Community bonding period: study of MediaWiki's components related to the project, discuss best way to do things.
- 2-3 weeks: exact specification and architectural design
- 2-3 weeks: prototyping
Milestone 1: basic working version
- 4 weeks: improvements on code and functionality; more advanced features
- 2 weeks: testing and documentation
This could leave room for something in the "if time permits" section.
I will often hang on #mediawiki for discussion or clarification of any doubt; I could use other channels (e.g. mailing list) if needed.
I would work on a local installation of MediaWiki, with frequent commit to a branch in the SVN repository. At some point, setting up a live test wiki could become more practical.
Past open source experience
I don't have any past experience in open source projects, but I'm quite used to write client side code for user interface customizations, as I said above.
I implemented a small feature for MediaWiki in 2005 (it was about a very rudimental idea similar to “pending changes”, when nobody still talked about that; I needed the feature for a personal wiki). I finished an initial version, but I eventually stopped working on the project and it went lost on some unused branch of the repository (as far as I know, nobody reviewed it).
Any other info
An example of how the configuration object could look like is at this subpage.