The Battle for Wesnoth Wiki - User contributions [en]

User:Vinipsmaker/GSoC13/Proposal

2013-05-20T19:29:08Z

Vinipsmaker: /* Timeline */

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

=== The WML-based database ===

In this project, I'd only implement one concrete backend, the ''WML-based database backend''. This backend would use WML config files and would serve as an example to implement new backends.

This database would separate the add-on data from its meta-data. The meta-data would be saved in a child tag of the main add-on's config file. Extra meta-data will be stored there also.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

An extra meta-data example is the ''number of players''. Currently there is no field to describe the ''number of players'', but in the future developers may want to add this feature (and players could start using it ASAP).

The support to extra meta-data influence the database and the network protocol. If you want info about how they solve the new problem, see the appropriate section.

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Event loop != boost::io_service ===

The boost::io_service object has [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/run.html an option] to act as an event loop, but this option may be suboptiomal when we want to schedule our own actions. Suppose we need to acquire some mutex, then we can't use ''[http://www.boost.org/doc/libs/1_42_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts.lockable.try_lock try_lock]'' because we can't schedule our own actions if it's not I/O related. So, I'd implement my own event loop class, allowing anyone to register its own actions and [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/poll.html integrate it with io_service].

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to block the current event loop as little as possible.

[http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300 Use one boost::io_service per thread] decreases the contention when locking the io_service internal mutex for queuing and dequeuing
requests and is preferred for maximum scalability.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
*** If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data. The SimpleAddonManager (WML-based database), like the config file, store its metadata in WML.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

==== journal.log ====

When some update is requested, the add-on server may update data in several different places. If a crash happens in the middle of the update, the data may corrupt. This database is not meant to support full [http://en.wikipedia.org/wiki/ACID ACID semantics], but it'll provide [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomicity] to prevent severe data loss, while a new backend is not developed.

The main implementation technique is to use a journal file, storing when an operation starts and when it ends. Implement atomicity in this database is a requirement of this proposal, but the ''journal.log'' is optional and I might choose a different technique.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (similar, but not equal, to HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users. '''The message errors will still be WML-based.'''
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

==== SSL ====

[http://en.wikipedia.org/wiki/Secure_Socket_Layer SSL] is the standard protocol atop of sockets used to securely comunicate between two entities. It doesn't provide much advantage when you only intends to download an add-on, but it's very useful when you want to protect your password from eavesdroppers and alike.

The Wesnoth client could add a configuration to choose ''secure connection'' and use unsecure connection by default (decreasing this overhead on the server).

The add-on server would provide both (unencrypted and encrypted) connections. It'd listen to two ports to differentiate the connection type.

[http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference.html Boost::asio] already provides support for SSL and add it in the add-on server would be easy.

== Timeline ==

{| class="wikitable"
|-
! Period !! Task !! Status !! Notes
|-
| Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server.
| bgcolor="#00FF00" | DONE
|| Debian 6.0 (squeeze) with [http://wiki.wesnoth.org/CompilingWesnoth#Prerequisites all Wesnoth build deps] (tested)
|-
| Week 0 (May 19 to 25) || Create a Wesnoth branch and start coding. Get used to Boost.asio. || Mandatory ||
|-
| Week 1-2 (May 26 till June 8) || Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. || Mandatory || The base to better meta-data and i18n support.
|-
| Week 3 (June 9 to 15) || Reimplement a subset of the current protocol in Boost.asio. || Optional ||
* This feature will depend on the event loop
* It'll delegate the '''read''' operations to the database
|-
| Week 4 (June 16 to 22) || Start working on the authentication support. || Mandatory || The standalone login backend won't support access control groups
|-
| Week 5-7 (June 23 till July 13) || Implement the new protocol || Mandatory ||
* It'll delegate '''read''' and '''write''' operations to the database.
* It'll be integrated with the authentication support.
* Documentation should follow it progress.
|-
| Week 8 (July 14 to 20) || Introduce threads || Mandatory ||
|-
| Week 8 (July 14 to 20) || Introduce SSL || Optional ||
|-
| Week 9-11 (July 21 till August 10) || LDAP support || Mandatory || It may take less time, but I'm overestimating because I have little experience with LDAP (only as a sysadmin at [http://en.lccv.ufal.br/cluster/ LCCV] for a while)
|-
| Week 12 (August 11 to 17) || Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch || Mandatory ||
|-
| Week 13-16 (August 18 till September 14) || Integrate the new protocol in Wesnoth client. || Mandatory ||
|}

I overestimated all tasks, so I may finish some tasks a bit sooner and use this time to compensate the wrongly estimated tasks, but this made the timeline lose some precision.

=== Threads in wiki 8 ===

Usually it's advised to introduce threads in the initial '''design''' of the application if someone wants to support multithread design. A rule of dumb is to take a step further and make threads part of the initial '''code'''.

In this proposal, I suggest to introduce threads only at week 8, but I already have experience with multi-threaded programs and I'd make the design ready to be extended right from the week 1. The reason why I want to introduce threads later is because I want to deliver something usable sooner and work incrementally till deliver the full product.

I like to work incrementally, because you catch specifications errors sooner (users not usually know what they want till you deliver the product and they say "Hey! This is not what I asked for!").

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-19T22:52:02Z

Vinipsmaker: /* Timeline */

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

=== The WML-based database ===

In this project, I'd only implement one concrete backend, the ''WML-based database backend''. This backend would use WML config files and would serve as an example to implement new backends.

This database would separate the add-on data from its meta-data. The meta-data would be saved in a child tag of the main add-on's config file. Extra meta-data will be stored there also.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

An extra meta-data example is the ''number of players''. Currently there is no field to describe the ''number of players'', but in the future developers may want to add this feature (and players could start using it ASAP).

The support to extra meta-data influence the database and the network protocol. If you want info about how they solve the new problem, see the appropriate section.

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Event loop != boost::io_service ===

The boost::io_service object has [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/run.html an option] to act as an event loop, but this option may be suboptiomal when we want to schedule our own actions. Suppose we need to acquire some mutex, then we can't use ''[http://www.boost.org/doc/libs/1_42_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts.lockable.try_lock try_lock]'' because we can't schedule our own actions if it's not I/O related. So, I'd implement my own event loop class, allowing anyone to register its own actions and [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/poll.html integrate it with io_service].

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to block the current event loop as little as possible.

[http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300 Use one boost::io_service per thread] decreases the contention when locking the io_service internal mutex for queuing and dequeuing
requests and is preferred for maximum scalability.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
*** If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data. The SimpleAddonManager (WML-based database), like the config file, store its metadata in WML.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

==== journal.log ====

When some update is requested, the add-on server may update data in several different places. If a crash happens in the middle of the update, the data may corrupt. This database is not meant to support full [http://en.wikipedia.org/wiki/ACID ACID semantics], but it'll provide [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomicity] to prevent severe data loss, while a new backend is not developed.

The main implementation technique is to use a journal file, storing when an operation starts and when it ends. Implement atomicity in this database is a requirement of this proposal, but the ''journal.log'' is optional and I might choose a different technique.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (similar, but not equal, to HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users. '''The message errors will still be WML-based.'''
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

==== SSL ====

[http://en.wikipedia.org/wiki/Secure_Socket_Layer SSL] is the standard protocol atop of sockets used to securely comunicate between two entities. It doesn't provide much advantage when you only intends to download an add-on, but it's very useful when you want to protect your password from eavesdroppers and alike.

The Wesnoth client could add a configuration to choose ''secure connection'' and use unsecure connection by default (decreasing this overhead on the server).

The add-on server would provide both (unencrypted and encrypted) connections. It'd listen to two ports to differentiate the connection type.

[http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference.html Boost::asio] already provides support for SSL and add it in the add-on server would be easy.

== Timeline ==

{| class="wikitable"
|-
! Period !! Task !! Status !! Notes
|-
| Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server.
| bgcolor="#00FF00" | DONE
|| Debian 6.0 (squeeze) with [http://wiki.wesnoth.org/CompilingWesnoth#Prerequisites all Wesnoth build deps] (tested)
|-
| Week 0 (May 19 to 25) || Create a Wesnoth branch and start coding. Get used to Boost.asio. || Mandatory ||
|-
| Week 1-2 (May 26 till June 8) || Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. || Mandatory || The base to better meta-data and i18n support.
|-
| Week 3 (June 9 to 15) || Reimplement a subset of the current protocol in Boost.asio. || Optional ||
* This feature will depend on the event loop
* It'll delegate the '''read''' operations to the database
|-
| Week 4 (June 16 to 22) || Start working on the authentication support. || Mandatory || The standalone login backend won't support access control groups
|-
| Week 5-7 (June 23 till July 13) || Implement the new protocol || Mandatory ||
* It'll delegate '''read''' and '''write''' operations to the database.
* It'll be integrated with the authentication support.
* Documentation should follow it progress.
|-
| Week 8 (July 14 to 20) || Introduce threads and SSL. || Mandatory for threads and optional for SSL ||
|-
| Week 9-11 (July 21 till August 10) || LDAP support || Mandatory || It may take less time, but I'm overestimating because I have little experience with LDAP (only as a sysadmin at [http://en.lccv.ufal.br/cluster/ LCCV] for a while)
|-
| Week 12 (August 11 to 17) || Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch || Mandatory ||
|-
| Week 13-16 (August 18 till September 14) || Integrate the new protocol in Wesnoth client. || Mandatory ||
|}

I overestimated all tasks, so I may finish some tasks a bit sooner and use this time to compensate the wrongly estimated tasks, but this made the timeline lose some precision.

=== Threads in wiki 8 ===

Usually it's advised to introduce threads in the initial '''design''' of the application if someone wants to support multithread design. A rule of dumb is to take a step further and make threads part of the initial '''code'''.

In this proposal, I suggest to introduce threads only at week 8, but I already have experience with multi-threaded programs and I'd make the design ready to be extended right from the week 1. The reason why I want to introduce threads later is because I want to deliver something usable sooner and work incrementally till deliver the full product.

I like to work incrementally, because you catch specifications errors sooner (users not usually know what they want till you deliver the product and they say "Hey! This is not what I asked for!").

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-19T22:41:04Z

Vinipsmaker: /* Timeline */

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

=== The WML-based database ===

In this project, I'd only implement one concrete backend, the ''WML-based database backend''. This backend would use WML config files and would serve as an example to implement new backends.

This database would separate the add-on data from its meta-data. The meta-data would be saved in a child tag of the main add-on's config file. Extra meta-data will be stored there also.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

An extra meta-data example is the ''number of players''. Currently there is no field to describe the ''number of players'', but in the future developers may want to add this feature (and players could start using it ASAP).

The support to extra meta-data influence the database and the network protocol. If you want info about how they solve the new problem, see the appropriate section.

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Event loop != boost::io_service ===

The boost::io_service object has [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/run.html an option] to act as an event loop, but this option may be suboptiomal when we want to schedule our own actions. Suppose we need to acquire some mutex, then we can't use ''[http://www.boost.org/doc/libs/1_42_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts.lockable.try_lock try_lock]'' because we can't schedule our own actions if it's not I/O related. So, I'd implement my own event loop class, allowing anyone to register its own actions and [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/poll.html integrate it with io_service].

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to block the current event loop as little as possible.

[http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300 Use one boost::io_service per thread] decreases the contention when locking the io_service internal mutex for queuing and dequeuing
requests and is preferred for maximum scalability.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
*** If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data. The SimpleAddonManager (WML-based database), like the config file, store its metadata in WML.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

==== journal.log ====

When some update is requested, the add-on server may update data in several different places. If a crash happens in the middle of the update, the data may corrupt. This database is not meant to support full [http://en.wikipedia.org/wiki/ACID ACID semantics], but it'll provide [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomicity] to prevent severe data loss, while a new backend is not developed.

The main implementation technique is to use a journal file, storing when an operation starts and when it ends. Implement atomicity in this database is a requirement of this proposal, but the ''journal.log'' is optional and I might choose a different technique.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (similar, but not equal, to HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users. '''The message errors will still be WML-based.'''
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

==== SSL ====

[http://en.wikipedia.org/wiki/Secure_Socket_Layer SSL] is the standard protocol atop of sockets used to securely comunicate between two entities. It doesn't provide much advantage when you only intends to download an add-on, but it's very useful when you want to protect your password from eavesdroppers and alike.

The Wesnoth client could add a configuration to choose ''secure connection'' and use unsecure connection by default (decreasing this overhead on the server).

The add-on server would provide both (unencrypted and encrypted) connections. It'd listen to two ports to differentiate the connection type.

[http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference.html Boost::asio] already provides support for SSL and add it in the add-on server would be easy.

== Timeline ==

{| class="wikitable"
|-
! Period !! Task !! Status !! Notes
|-
| Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server.
| style="background: #00FF00;" | DONE
|| Debian 6.0 (squeeze) with [http://wiki.wesnoth.org/CompilingWesnoth#Prerequisites all Wesnoth build deps] (tested)
|-
| Week 0 (May 19 to 25) || Create a Wesnoth branch and start coding. Get used to Boost.asio. || Mandatory ||
|-
| Week 1-2 (May 26 till June 8) || Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. || Mandatory || The base to better meta-data and i18n support.
|-
| Week 3 (June 9 to 15) || Reimplement a subset of the current protocol in Boost.asio. || Optional ||
* This feature will depend on the event loop
* It'll delegate the '''read''' operations to the database
|-
| Week 4 (June 16 to 22) || Start working on the authentication support. || Mandatory || The standalone login backend won't support access control groups
|-
| Week 5-7 (June 23 till July 13) || Implement the new protocol || Mandatory ||
* It'll delegate '''read''' and '''write''' operations to the database.
* It'll be integrated with the authentication support.
* Documentation should follow it progress.
|-
| Week 8 (July 14 to 20) || Introduce threads and SSL. || Mandatory for threads and optional for SSL ||
|-
| Week 9-11 (July 21 till August 10) || LDAP support || Mandatory || It may take less time, but I'm overestimating because I have little experience with LDAP (only as a sysadmin at [http://en.lccv.ufal.br/cluster/ LCCV] for a while)
|-
| Week 12 (August 11 to 17) || Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch || Mandatory ||
|-
| Week 13-16 (August 18 till September 14) || Integrate the new protocol in Wesnoth client. || Mandatory ||
|}

I overestimated all tasks, so I may finish some tasks a bit sooner and use this time to compensate the wrongly estimated tasks, but this made the timeline lose some precision.

=== Threads in wiki 8 ===

Usually it's advised to introduce threads in the initial '''design''' of the application if someone wants to support multithread design. A rule of dumb is to take a step further and make threads part of the initial '''code'''.

In this proposal, I suggest to introduce threads only at week 8, but I already have experience with multi-threaded programs and I'd make the design ready to be extended right from the week 1. The reason why I want to introduce threads later is because I want to deliver something usable sooner and work incrementally till deliver the full product.

I like to work incrementally, because you catch specifications errors sooner (users not usually know what they want till you deliver the product and they say "Hey! This is not what I asked for!").

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-19T20:58:15Z

Vinipsmaker: fix small gramar issue

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

=== The WML-based database ===

In this project, I'd only implement one concrete backend, the ''WML-based database backend''. This backend would use WML config files and would serve as an example to implement new backends.

This database would separate the add-on data from its meta-data. The meta-data would be saved in a child tag of the main add-on's config file. Extra meta-data will be stored there also.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

An extra meta-data example is the ''number of players''. Currently there is no field to describe the ''number of players'', but in the future developers may want to add this feature (and players could start using it ASAP).

The support to extra meta-data influence the database and the network protocol. If you want info about how they solve the new problem, see the appropriate section.

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Event loop != boost::io_service ===

The boost::io_service object has [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/run.html an option] to act as an event loop, but this option may be suboptiomal when we want to schedule our own actions. Suppose we need to acquire some mutex, then we can't use ''[http://www.boost.org/doc/libs/1_42_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts.lockable.try_lock try_lock]'' because we can't schedule our own actions if it's not I/O related. So, I'd implement my own event loop class, allowing anyone to register its own actions and [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/poll.html integrate it with io_service].

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to block the current event loop as little as possible.

[http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300 Use one boost::io_service per thread] decreases the contention when locking the io_service internal mutex for queuing and dequeuing
requests and is preferred for maximum scalability.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
*** If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data. The SimpleAddonManager (WML-based database), like the config file, store its metadata in WML.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

==== journal.log ====

When some update is requested, the add-on server may update data in several different places. If a crash happens in the middle of the update, the data may corrupt. This database is not meant to support full [http://en.wikipedia.org/wiki/ACID ACID semantics], but it'll provide [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomicity] to prevent severe data loss, while a new backend is not developed.

The main implementation technique is to use a journal file, storing when an operation starts and when it ends. Implement atomicity in this database is a requirement of this proposal, but the ''journal.log'' is optional and I might choose a different technique.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (similar, but not equal, to HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users. '''The message errors will still be WML-based.'''
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

==== SSL ====

[http://en.wikipedia.org/wiki/Secure_Socket_Layer SSL] is the standard protocol atop of sockets used to securely comunicate between two entities. It doesn't provide much advantage when you only intends to download an add-on, but it's very useful when you want to protect your password from eavesdroppers and alike.

The Wesnoth client could add a configuration to choose ''secure connection'' and use unsecure connection by default (decreasing this overhead on the server).

The add-on server would provide both (unencrypted and encrypted) connections. It'd listen to two ports to differentiate the connection type.

[http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference.html Boost::asio] already provides support for SSL and add it in the add-on server would be easy.

== Timeline ==

{| class="wikitable"
|-
! Period !! Task !! Status !! Notes
|-
| Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server. || Mandatory ||
|-
| Week 0 (May 19 to 25) || Create a Wesnoth branch and start coding. Get used to Boost.asio. || Mandatory ||
|-
| Week 1-2 (May 26 till June 8) || Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. || Mandatory || The base to better meta-data and i18n support.
|-
| Week 3 (June 9 to 15) || Reimplement a subset of the current protocol in Boost.asio. || Optional ||
* This feature will depend on the event loop
* It'll delegate the '''read''' operations to the database
|-
| Week 4 (June 16 to 22) || Start working on the authentication support. || Mandatory || The standalone login backend won't support access control groups
|-
| Week 5-7 (June 23 till July 13) || Implement the new protocol || Mandatory ||
* It'll delegate '''read''' and '''write''' operations to the database.
* It'll be integrated with the authentication support.
* Documentation should follow it progress.
|-
| Week 8 (July 14 to 20) || Introduce threads and SSL. || Mandatory for threads and optional for SSL ||
|-
| Week 9-11 (July 21 till August 10) || LDAP support || Mandatory || It may take less time, but I'm overestimating because I have little experience with LDAP (only as a sysadmin at [http://en.lccv.ufal.br/cluster/ LCCV] for a while)
|-
| Week 12 (August 11 to 17) || Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch || Mandatory ||
|-
| Week 13-16 (August 18 till September 14) || Integrate the new protocol in Wesnoth client. || Mandatory ||
|}

I overestimated all tasks, so I may finish some tasks a bit sooner and use this time to compensate the wrongly estimated tasks, but this made the timeline lose some precision.

=== Threads in wiki 8 ===

Usually it's advised to introduce threads in the initial '''design''' of the application if someone wants to support multithread design. A rule of dumb is to take a step further and make threads part of the initial '''code'''.

In this proposal, I suggest to introduce threads only at week 8, but I already have experience with multi-threaded programs and I'd make the design ready to be extended right from the week 1. The reason why I want to introduce threads later is because I want to deliver something usable sooner and work incrementally till deliver the full product.

I like to work incrementally, because you catch specifications errors sooner (users not usually know what they want till you deliver the product and they say "Hey! This is not what I asked for!").

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-19T20:11:45Z

Vinipsmaker: /* Event loop != boost::io_service */

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

=== The WML-based database ===

In this project, I'd only implement one concrete backend, the ''WML-based database backend''. This backend would use WML config files and would serve as an example to implement new backends.

This database would separate the add-on data from its meta-data. The meta-data would be saved in a child tag of the main add-on's config file. Extra meta-data will be stored there also.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

An extra meta-data example is the ''number of players''. Currently there is no field to describe the ''number of players'', but in the future developers may want to add this feature (and players could start using it ASAP).

The support to extra meta-data influence the database and the network protocol. If you want info about how they solve the new problem, see the appropriate section.

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Event loop != boost::io_service ===

The boost::io_service object has [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/run.html an option] to act as an event loop, but this option may be suboptiomal when we want to schedule our own actions. Suppose we need to acquire some mutex, then we can't use ''[http://www.boost.org/doc/libs/1_42_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts.lockable.try_lock try_lock]'' because we can't schedule our own actions if it's not I/O related. So, I'd implement my own event loop class, allowing anyone to register its own actions and [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/poll.html integrate it with io_service].

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to block the current event loop as little as possible.

[http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300 Use one boost::io_service per thread] decreases the contention when locking the io_service internal mutex for queuing and dequeuing
requests and is preferred for maximum scalability.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
*** If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data. The SimpleAddonManager (WML-based database), like the config file, store its metadata in WML.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

==== journal.log ====

When some update is requested, the add-on server may update data in several different places. If a crash happens in the middle of the update, the data may corrupt. This database is not meant to support full [http://en.wikipedia.org/wiki/ACID ACID semantics], but it'll provide [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomicity] to prevent severe data loss, while a new backend is not developed.

The main implementation technique is to use a journal file, storing when an operation starts and when it ends. Implement atomicity in this database is a requirement of this proposal, but the ''journal.log'' is optional and I might choose a different technique.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (similar, but not equal, to HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users. '''The message errors will still be WML-based.'''
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

==== SSL ====

[http://en.wikipedia.org/wiki/Secure_Socket_Layer SSL] is the standard protocol atop of sockets used to securely comunicate between two entities. It doesn't provide much advantage when you only intends to download an add-on, but it's very useful when you want to protect your password from eavesdroppers and alike.

The Wesnoth client could add a configuration to choose ''secure connection'' and use unsecure connection by default (decreasing this overhead on the server).

The add-on server would provide both (unencrypted and encrypted) connections. It'd listen to two ports to differentiate the connection type.

[http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference.html Boost::asio] already provides support for SSL and add it in the add-on server would be easy.

== Timeline ==

{| class="wikitable"
|-
! Period !! Task !! Status !! Notes
|-
| Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server. || Mandatory ||
|-
| Week 0 (May 19 to 25) || Create a Wesnoth branch and start coding. Get used to Boost.asio. || Mandatory ||
|-
| Week 1-2 (May 26 till June 8) || Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. || Mandatory || The base to better meta-data and i18n support.
|-
| Week 3 (June 9 to 15) || Reimplement a subset of the current protocol in Boost.asio. || Optional ||
* This feature will depends on the event loop
* It'll delegate the '''read''' operations to the database
|-
| Week 4 (June 16 to 22) || Start working on the authentication support. || Mandatory || The standalone login backend won't support access control groups
|-
| Week 5-7 (June 23 till July 13) || Implement the new protocol || Mandatory ||
* It'll delegate '''read''' and '''write''' operations to the database.
* It'll be integrated with the authentication support.
* Documentation should follow it progress.
|-
| Week 8 (July 14 to 20) || Introduce threads and SSL. || Mandatory for threads and optional for SSL ||
|-
| Week 9-11 (July 21 till August 10) || LDAP support || Mandatory || It may take less time, but I'm overestimating because I have little experience with LDAP (only as a sysadmin at [http://en.lccv.ufal.br/cluster/ LCCV] for a while)
|-
| Week 12 (August 11 to 17) || Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch || Mandatory ||
|-
| Week 13-16 (August 18 till September 14) || Integrate the new protocol in Wesnoth client. || Mandatory ||
|}

I overestimated all tasks, so I may finish some tasks a bit sooner and use this time to compensate the wrongly estimated tasks, but this made the timeline lose some precision.

=== Threads in wiki 8 ===

Usually it's advised to introduce threads in the initial '''design''' of the application if someone wants to support multithread design. A rule of dumb is to take a step further and make threads part of the initial '''code'''.

In this proposal, I suggest to introduce threads only at week 8, but I already have experience with multi-threaded programs and I'd make the design ready to be extended right from the week 1. The reason why I want to introduce threads later is because I want to deliver something usable sooner and work incrementally till deliver the full product.

I like to work incrementally, because you catch specifications errors sooner (users not usually know what they want till you deliver the product and they say "Hey! This is not what I asked for!").

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-19T20:03:55Z

Vinipsmaker: /* Timeline */

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

=== The WML-based database ===

In this project, I'd only implement one concrete backend, the ''WML-based database backend''. This backend would use WML config files and would serve as an example to implement new backends.

This database would separate the add-on data from its meta-data. The meta-data would be saved in a child tag of the main add-on's config file. Extra meta-data will be stored there also.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

An extra meta-data example is the ''number of players''. Currently there is no field to describe the ''number of players'', but in the future developers may want to add this feature (and players could start using it ASAP).

The support to extra meta-data influence the database and the network protocol. If you want info about how they solve the new problem, see the appropriate section.

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Event loop != boost::io_service ===

The boost::io_service object has [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/run.html an option] to act as an event loop, but this option may be suboptiomal when we want to schedule our own actions. So, I'd implement my own event loop class, allowing anyone to register its own actions and [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/poll.html integrate it with io_service].

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to block the current event loop as little as possible.

[http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300 Use one boost::io_service per thread] decreases the contention when locking the io_service internal mutex for queuing and dequeuing
requests and is preferred for maximum scalability.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
*** If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data. The SimpleAddonManager (WML-based database), like the config file, store its metadata in WML.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

==== journal.log ====

When some update is requested, the add-on server may update data in several different places. If a crash happens in the middle of the update, the data may corrupt. This database is not meant to support full [http://en.wikipedia.org/wiki/ACID ACID semantics], but it'll provide [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomicity] to prevent severe data loss, while a new backend is not developed.

The main implementation technique is to use a journal file, storing when an operation starts and when it ends. Implement atomicity in this database is a requirement of this proposal, but the ''journal.log'' is optional and I might choose a different technique.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (similar, but not equal, to HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users. '''The message errors will still be WML-based.'''
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

==== SSL ====

[http://en.wikipedia.org/wiki/Secure_Socket_Layer SSL] is the standard protocol atop of sockets used to securely comunicate between two entities. It doesn't provide much advantage when you only intends to download an add-on, but it's very useful when you want to protect your password from eavesdroppers and alike.

The Wesnoth client could add a configuration to choose ''secure connection'' and use unsecure connection by default (decreasing this overhead on the server).

The add-on server would provide both (unencrypted and encrypted) connections. It'd listen to two ports to differentiate the connection type.

[http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference.html Boost::asio] already provides support for SSL and add it in the add-on server would be easy.

== Timeline ==

{| class="wikitable"
|-
! Period !! Task !! Status !! Notes
|-
| Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server. || Mandatory ||
|-
| Week 0 (May 19 to 25) || Create a Wesnoth branch and start coding. Get used to Boost.asio. || Mandatory ||
|-
| Week 1-2 (May 26 till June 8) || Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. || Mandatory || The base to better meta-data and i18n support.
|-
| Week 3 (June 9 to 15) || Reimplement a subset of the current protocol in Boost.asio. || Optional ||
* This feature will depends on the event loop
* It'll delegate the '''read''' operations to the database
|-
| Week 4 (June 16 to 22) || Start working on the authentication support. || Mandatory || The standalone login backend won't support access control groups
|-
| Week 5-7 (June 23 till July 13) || Implement the new protocol || Mandatory ||
* It'll delegate '''read''' and '''write''' operations to the database.
* It'll be integrated with the authentication support.
* Documentation should follow it progress.
|-
| Week 8 (July 14 to 20) || Introduce threads and SSL. || Mandatory for threads and optional for SSL ||
|-
| Week 9-11 (July 21 till August 10) || LDAP support || Mandatory || It may take less time, but I'm overestimating because I have little experience with LDAP (only as a sysadmin at [http://en.lccv.ufal.br/cluster/ LCCV] for a while)
|-
| Week 12 (August 11 to 17) || Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch || Mandatory ||
|-
| Week 13-16 (August 18 till September 14) || Integrate the new protocol in Wesnoth client. || Mandatory ||
|}

I overestimated all tasks, so I may finish some tasks a bit sooner and use this time to compensate the wrongly estimated tasks, but this made the timeline lose some precision.

=== Threads in wiki 8 ===

Usually it's advised to introduce threads in the initial '''design''' of the application if someone wants to support multithread design. A rule of dumb is to take a step further and make threads part of the initial '''code'''.

In this proposal, I suggest to introduce threads only at week 8, but I already have experience with multi-threaded programs and I'd make the design ready to be extended right from the week 1. The reason why I want to introduce threads later is because I want to deliver something usable sooner and work incrementally till deliver the full product.

I like to work incrementally, because you catch specifications errors sooner (users not usually know what they want till you deliver the product and they say "Hey! This is not what I asked for!").

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-19T19:02:25Z

Vinipsmaker: timeline: convert from list to table

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

=== The WML-based database ===

In this project, I'd only implement one concrete backend, the ''WML-based database backend''. This backend would use WML config files and would serve as an example to implement new backends.

This database would separate the add-on data from its meta-data. The meta-data would be saved in a child tag of the main add-on's config file. Extra meta-data will be stored there also.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

An extra meta-data example is the ''number of players''. Currently there is no field to describe the ''number of players'', but in the future developers may want to add this feature (and players could start using it ASAP).

The support to extra meta-data influence the database and the network protocol. If you want info about how they solve the new problem, see the appropriate section.

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Event loop != boost::io_service ===

The boost::io_service object has [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/run.html an option] to act as an event loop, but this option may be suboptiomal when we want to schedule our own actions. So, I'd implement my own event loop class, allowing anyone to register its own actions and [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/poll.html integrate it with io_service].

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to block the current event loop as little as possible.

[http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300 Use one boost::io_service per thread] decreases the contention when locking the io_service internal mutex for queuing and dequeuing
requests and is preferred for maximum scalability.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
*** If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data. The SimpleAddonManager (WML-based database), like the config file, store its metadata in WML.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

==== journal.log ====

When some update is requested, the add-on server may update data in several different places. If a crash happens in the middle of the update, the data may corrupt. This database is not meant to support full [http://en.wikipedia.org/wiki/ACID ACID semantics], but it'll provide [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomicity] to prevent severe data loss, while a new backend is not developed.

The main implementation technique is to use a journal file, storing when an operation starts and when it ends. Implement atomicity in this database is a requirement of this proposal, but the ''journal.log'' is optional and I might choose a different technique.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (similar, but not equal, to HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users. '''The message errors will still be WML-based.'''
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

==== SSL ====

[http://en.wikipedia.org/wiki/Secure_Socket_Layer SSL] is the standard protocol atop of sockets used to securely comunicate between two entities. It doesn't provide much advantage when you only intends to download an add-on, but it's very useful when you want to protect your password from eavesdroppers and alike.

The Wesnoth client could add a configuration to choose ''secure connection'' and use unsecure connection by default (decreasing this overhead on the server).

The add-on server would provide both (unencrypted and encrypted) connections. It'd listen to two ports to differentiate the connection type.

[http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference.html Boost::asio] already provides support for SSL and add it in the add-on server would be easy.

== Timeline ==

{| class="wikitable"
|-
! Period !! Task !! Status !! Notes
|-
| Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server. || Mandatory ||
|-
| Week 0 (May 19 to 25) || Create a Wesnoth branch and start coding. Get used to Boost.asio. || Mandatory ||
|-
| Week 1-2 (May 26 till June 8) || Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. || Mandatory ||
|-
| Week 3 (June 9 to 15) || Reimplement the current protocol in Boost.asio. || Mandatory ||
|-
| Week 4 (June 16 to 22) || Start working on the authentication support. || Mandatory ||
|-
| Week 5-7 (June 23 till July 13) || Implement the new protocol || Mandatory || Documentation should follow it progress.
|-
| Week 8 (July 14 to 20) || Introduce threads and SSL. || Mandatory ||
|-
| Week 9-11 (July 21 till August 10) || LDAP support || Mandatory ||
|-
| Week 12 (August 11 to 17) || Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch || Mandatory ||
|-
| Week 13-16 (August 18 till September 14) || Integrate the new protocol in Wesnoth client. || Mandatory ||
|}

I overestimated all tasks, so I may finish some tasks a bit sooner and use this time to compensate the wrongly estimated tasks, but this made the timeline lose some precision.

=== Threads in wiki 8 ===

Usually it's advised to introduce threads in the initial '''design''' of the application if someone wants to support multithread design. A rule of dumb is to take a step further and make threads part of the initial '''code'''.

In this proposal, I suggest to introduce threads only at week 8, but I already have experience with multi-threaded programs and I'd make the design ready to be extended right from the week 1. The reason why I want to introduce threads later is because I want to deliver something usable sooner and work incrementally till deliver the full product.

I like to work incrementally, because you catch specifications errors sooner (users not usually know what they want till you deliver the product and they say "Hey! This is not what I asked for!").

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-17T20:49:57Z

Vinipsmaker:

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

=== The WML-based database ===

In this project, I'd only implement one concrete backend, the ''WML-based database backend''. This backend would use WML config files and would serve as an example to implement new backends.

This database would separate the add-on data from its meta-data. The meta-data would be saved in a child tag of the main add-on's config file. Extra meta-data will be stored there also.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

An extra meta-data example is the ''number of players''. Currently there is no field to describe the ''number of players'', but in the future developers may want to add this feature (and players could start using it ASAP).

The support to extra meta-data influence the database and the network protocol. If you want info about how they solve the new problem, see the appropriate section.

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Event loop != boost::io_service ===

The boost::io_service object has [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/run.html an option] to act as an event loop, but this option may be suboptiomal when we want to schedule our own actions. So, I'd implement my own event loop class, allowing anyone to register its own actions and [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference/io_service/poll.html integrate it with io_service].

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to block the current event loop as little as possible.

[http://thread.gmane.org/gmane.comp.lib.boost.asio.user/1300 Use one boost::io_service per thread] decreases the contention when locking the io_service internal mutex for queuing and dequeuing
requests and is preferred for maximum scalability.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
*** If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data. The SimpleAddonManager (WML-based database), like the config file, store its metadata in WML.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

==== journal.log ====

When some update is requested, the add-on server may update data in several different places. If a crash happens in the middle of the update, the data may corrupt. This database is not meant to support full [http://en.wikipedia.org/wiki/ACID ACID semantics], but it'll provide [http://en.wikipedia.org/wiki/Atomicity_(database_systems) atomicity] to prevent severe data loss, while a new backend is not developed.

The main implementation technique is to use a journal file, storing when an operation starts and when it ends. Implement atomicity in this database is a requirement of this proposal, but the ''journal.log'' is optional and I might choose a different technique.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (similar, but not equal, to HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users. '''The message errors will still be WML-based.'''
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

==== SSL ====

[http://en.wikipedia.org/wiki/Secure_Socket_Layer SSL] is the standard protocol atop of sockets used to securely comunicate between two entities. It doesn't provide much advantage when you only intends to download an add-on, but it's very useful when you want to protect your password from eavesdroppers and alike.

The Wesnoth client could add a configuration to choose ''secure connection'' and use unsecure connection by default (decreasing this overhead on the server).

The add-on server would provide both (unencrypted and encrypted) connections. It'd listen to two ports to differentiate the connection type.

[http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/reference.html Boost::asio] already provides support for SSL and add it in the add-on server would be easy.

== Timeline ==

* Week -1 (May 12 to 18): Install a Debian chroot in my system that mimics Wesnoth main server. ''(mandatory)''
* Week 0 (May 19 to 25): Create a Wesnoth branch and start coding. Get used to Boost.asio ''(mandatory)''
* Week 1-2 (May 26 till June 8): Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. ''(mandatory)''
* Week 3 (June 9 to 15): Reimplement the current protocol in Boost.asio. ''(mandatory)''
* Week 4 (June 16 to 22): Start working on the authentication support ''(mandatory)''
* Week 5-7 (June 23 till July 13): Implement the new protocol (documentation should follow it progress). ''(mandatory)''
* Week 8 (July 14 to 20): Introduce threads and SSL ''(mandatory)''
* Week 9-11 (July 21 till August 10): LDAP support ''(mandatory)''
* Week 12 (August 11 to 17): Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch ''(mandatory)''
* Week 13-16 (August 18 till September 14): Integrate the new protocol in Wesnoth client ''(mandatory)''

I overestimated all tasks, so I may finish some tasks a bit sooner and use this time to compensate the wrongly estimated tasks, but this made the timeline lose some precision.

=== Threads in wiki 8 ===

Usually it's advised to introduce threads in the initial '''design''' of the application if someone wants to support multithread design. A rule of dumb is to take a step further and make threads part of the initial '''code'''.

In this proposal, I suggest to introduce threads only at week 8, but I already have experience with multi-threaded programs and I'd make the design ready to be extended right from the week 1. The reason why I want to introduce threads later is because I want to deliver something usable sooner and work incrementally till deliver the full product.

I like to work incrementally, because you catch specifications errors sooner (users not usually know what they want till you deliver the product and they say "Hey! This is not what I asked for!").

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-09T05:30:35Z

Vinipsmaker:

= Proposal =

My proposal is to create a new addon server from scratch, using a modular design easy to extend and built on top of Boost asio. The objectives of the new server are:

* Use a fully documented modular design
* Use [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [http://www.kegel.com/c10k.html])
** Better performance and scalability are the main objectives of this proposal
* Use RAII extensively to provide good support for exceptions and avoid leaks (something essential to any code that is intended to run for ages)
* Support multiple login backends
* Support multiple database backends (but only one would be implemented in this GSoC)
* Better metadata support (extra arguments shouldn't be silently discarded)
* Better localization and internationalization support
* Store all versions of the addons

You can see a '''draft''' (remember: it's a draft and its purpose is to explain what strategies will be used to solve the problems faced; the future system will probably implement some things undocumented here) below:

== Support multiple login backends ==

The aim of this feature is to provide a system ready-to-use on the ship date with its own database of users and a LDAP backend for future integration with the remaining Wesnoth online services. I would provide both backends (self and ldap) in this project.

The users would belong to some groups and the groups should be used to create an acess control. It should exist a group for the translation team with power to upload translations and it should exist a group for the admins (with unrestricted powers). The simple/self login backend wouldn't implement groups.

== Support multiple database backends ==

The server architecture would abstract data CRUD (create, retrieve, update, delete) to allow different servers to be used.

In this project, I'd only implement one concrete backend. This backend would use WML config files and would serve as an example to implement new backends.

A migration script will be provided to convert the add-ons from the previous format to the new one.

== Better metadata support ==

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed and cannot be extended (extra metadata is silently discarded). This project aims to better handle the metadata. Some features would be:

* The server would allow the use of custom icons. Currently is required to use an icon that is already installed.
* Extra metadata wouldn't be discarded. This feature aims to provide better extensibility.
* Allow the use of metadata in query requests (eg. only show addons of type ''campaign'')

== Better localization and internationalization support ==

Currently, there is no integration between the Addon Server and the [[WesCamp]] translations. A [https://github.com/wesnoth/wesnoth-old/blob/master/data/tools/wesnoth/wescamp.py script] is run [http://wiki.wesnoth.org/Wescamp.py_Instructions by hand] every time the translations need to be updated.

The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).

It should be too difficult for the server to watch for the notifications and the requirement of the use of older tools/dependencies make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself.

The translator should send the translation to the translation team and the translation team could use their users (with some administrative power) to upload the translation to the server through the Wesnoth client, with a system similar to the [[PblWML|.pbl files]].

== Architecture ==

The server would be built on top of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio.html boost.asio] and would run a fixed number of threads. Each thread would run its own event loop, maximizing the possible number of concurrent clients.

An early draft of the components is shown below:

http://vinipsmaker.googlecode.com/files/architecture.png

To avoid locking a thread for more time than necessary, the EventLoop class would allow to register a delayed action in some queue. The actions that require lock would use try_lock (in conjunction with lock guard, to maintain the RAII idiom) in combination with delayed actions to maintain a lock as little as possible.

Different versions of the same protocol may share a lot of actions in common. To avoid code duplication, the session component will use [http://en.wikipedia.org/wiki/Factory_method_pattern factories] to instantiate the necessary handlers for each protocol and each handler will delegate the handling of every specific action to other classes.

Namespaces will be used to group classes related to protocols/versions.

=== Config files ===

The configuration file syntax would be a WML file with the following elements:

* ''umcd'' (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]): Top-level element
** old: The tag containing config related to the old (the current one) server
*** Port: Which port would run
** threads: The number of threads to use. Put 0 or don't put anything to let the server auto-detect through [http://www.boost.org/doc/libs/1_42_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency boost]
** database: It may contain several child tags to configure what database to use. If simple (the SimpleAddonManager) is chosen, you'd have the option to choose the directory data.
** Port: Which port it would use
** SSL: Settings related to SSL (key file, key file password, server port, ...)

=== SimpleAddonManager Filesystem layout ===

The SimpleAddonManager would save the add-ons using the following schema:

* ''/'': Top-level add-ons directory:
** ''add-ons.cfg''
** ''journal.log'': This '''won't''' be used to implement a full [http://en.wikipedia.org/wiki/ACID ACID] support, but it will provide basic guarantees to avoid severe data loss.
** ''Add-ons/''
*** ''Add-on name/''
**** ''metadata.cfg''
**** ''Add-on version/'': It would contain the add-on binary files related to ''version''.
***** ''i18n/'' (the name can be changed): It would contain the translation files. The version management would also be applied to translations and each translation should apply to a specific version of the add-on.
**** ''Another add-on version/'': It would contain the add-on binary files related to ''another version''.

== Protocol ==

The server would listen on some different ports:

* 15002: It would accept a subset of the protocol defined in [[CampaignServerWML]]. The objective is maintain backward compatibility with older Wesnoth clients. The commands '''not''' recognizable would be the ones related to uploading a campaign, changing the passphrase for a campaign, deleting a campaign and developer commands.
* 15003 (it's subject to change and can be any other): It would recognize the new protocol, as defined below.
* 15004 (it's subject to change and can be any other): The same as the previous one, but it would run atop of [http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/overview/ssl.html SSL].

=== The ''new'' protocol ===

The new protocol purpose is to address limitations faced in current protocol. For the new protocol, [[BinaryWML]] still will be used, to ease integration with Wesnoth client. The protocol is case-sensitive.

* From now on, messages will use error codes (like HTTP and JSON-RPC). This behaviour is useful to build automated tools and to show customized (read translated) message errors to users.
* The new messages will use a top-level tag named umc (the name is based on [http://hyc.io/wesnoth/umcd.pdf Trademark/mordante proposal]) and will have a version attribute. This attribute will extend the protocol in the future without break compatibility with older Wesnoth clients.

==== Version ''0'' ====

For version 0 (the one to be implemented during this GSoC), the following type of requests are supported:

* Listing supported version: The server should return a list of supported versions and the client can use this info to adapt itself to the server's limits.
* Listing available add-ons: It would replace the current [[CampaignServerWML#Listing_Available_Campaigns]]. In this command, every tag would be a filter with a syntax similar to [http://docs.mongodb.org/manual/reference/operator/#comparison MongoDB declarative queries syntax]. In version 0, only the following filter types are supported:
** date
** language
** [[PblWML#title]]: This attribute should be used if someone wants to receive info about a single add-on.
** [[PblWML#author]]
** [[PblWML#description]]: This tag will have child tags to allow translatable descriptions.
** [[PblWML#type]]
* Downloading an add-on: It will be possible to download a specific version of an add-on and its related translations.
* Uploading an add-on: It will have an ''auth'' child tag. It will have an ''ownership'' tag, with the following child tags:
** ''Type'': It can be ''password'', ''user'' or ''group''.
** ''Password'': Only if ''type'' is ''password''. It should be the campaign password (just like it works now).
** ''Auth'': It must be present if ''type'' is different from ''password''. It shall contain two child tags:
*** ''User'': The user's nickname.
*** ''Pass'': The user's password.
** ''add-on'': The add-on itself, with the child ''metadata'' and ''data'' tags. The ''data'' tag would contain the add-on file. The ''metadata'' tag could contain any extra child tags and they wouldn't be discarded (this is the behaviour adopted by [https://www.oasis-open.org/committees/download.php/19275/ ODF] to increase the interoperability).
* Edit an add-on: It could be used to edit an add-on's metadata, ownership or delete the add-on (or a specific version of it).
* Request uploading terms
* Submit translation: It will allow submit a translation (the description field would also be translated)

Some random notes about the new server/protocol:

* Multiple authors per add-on are possible
* The "''listing available add-ons''" request would use the following tags differently:
** ''Dependencies'': The list of dependencies would include a version (allowing the operators >, >=, <, <=, ==).
** ''Icon'': This different tag would contain the following child tags:
*** ''Type'': It can be ''link'' or ''png''. Future protocol versions can define different types.
*** ''Data'': The icon data. It can be a path to an image in the standard image directory for Wesnoth or a base64 encoded small PNG icon.
* Error messages would use a format similar to the [http://www.jsonrpc.org/specification#error_object JSON-RPC 2.0 error object]. The error message/object would contain three child tags:
** ''Code'': An integer specifying a previous documented value
** ''Message'': An english human-readable string with a description of the error. Clients can use the error code to show their own messages, possibly translated to the user's main language.
** ''Data'' (optional): Custom data with further details about the specific error.

== Timeline ==

* Week -1 (May 12 to 18): Install a Debian chroot in my system that mimics Wesnoth main server.
* Week 0 (May 19 to 25): Create a Wesnoth branch and start coding. Get used to Boost.asio
* Week 1-2 (May 26 till June 8): Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons.
* Week 3 (June 9 to 15): Reimplement the current protocol in Boost.asio.
* Week 4 (June 16 to 22): Start working on the authentication support
* Week 5-7 (June 23 till July 13): Implement the new protocol (documentation should follow it progress).
* Week 8 (July 14 to 20): Introduce threads and SSL
* Week 9-11 (July 21 till August 10): LDAP support
* Week 12 (August 11 to 17): Do more tests, fix bugs and integrate the new branch into the Wesnoth main branch
* Week 13-16 (August 18 till September 14): Integrate the new protocol in Wesnoth client

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of reasons can motivate me)

User:Vinipsmaker/GSoC13/Proposal

2013-05-06T05:34:28Z

Vinipsmaker: /* Better localization and internationalization support */

User:Vinipsmaker/GSoC13/Proposal

2013-05-06T05:32:31Z

Vinipsmaker: /* Better localization and internationalization support */

User:Vinipsmaker/GSoC13/Questionnaire

2013-05-06T01:17:47Z

Vinipsmaker:

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

My forum's username is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes, but this wouldn't be a problem, because I like to stay at home and I have a '''lot''' of spare time.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

I worked on a lot of projects. Among them:

* A very very simple enrollment system built on top of [http://nodejs.org/ Node.js asynchronous web frameowork for JavaScript]
* A bomberman-like networked Qt-game (it lacks several things I'm planning to release in a refactored version)
* I've worked on a private GStreamer plugin in C

Projects cited below aren't repeated here.

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I [https://github.com/wesnoth/wesnoth-old/pull/3 fixed] [https://gna.org/bugs/?20765 a bug within Wesnoth] and I [https://github.com/wesnoth/wesnoth-old/pull/5 refactored] a class to increase the use of the RAII idiom.

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* The first time a took a look at '''WML''' was this week, but this format reuses several patterns found in languages that I'm used to, such as preprocessor-like features from C, variables and expressions ressembling a bit of bash, the overall structure being a combination of INI and XML.
* My experience with '''Lua''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript, Java and MongoDB.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

User:Vinipsmaker/GSoC13

2013-05-03T20:08:39Z

Vinipsmaker:

{{SoC2013Student}}

You can see my <big>'''[[/Proposal]]'''</big> and my <big>'''[[/Questionnaire]]'''</big>'s answers.

User:Vinipsmaker/GSoC13/Questionnaire

2013-05-03T04:36:29Z

Vinipsmaker: /* 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. */

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

My forum's username is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes, but this wouldn't be a problem, because I like to stay at home and I have a '''lot''' of spare time.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

I worked on a lot of projects. Among them:

* A very very simple enrollment system built on top of [http://nodejs.org/ Node.js asynchronous web frameowork for JavaScript]
* A bomberman-like networked Qt-game (it lacks several things I'm planning to release in a refactored version)
* I've worked on a private GStreamer plugin in C

Projects cited below aren't repeated here.

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I fixed [https://gna.org/bugs/?20765 a bug within Wesnoth] and I'm waiting for the [https://github.com/wesnoth/wesnoth-old/pull/3 fix to being merged].

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* The first time a took a look at '''WML''' was this week, but this format reuses several patterns found in languages that I'm used to, such as preprocessor-like features from C, variables and expressions ressembling a bit of bash, the overall structure being a combination of INI and XML.
* My experience with '''Lua''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript, Java and MongoDB.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

User:Vinipsmaker/GSoC13/Proposal

2013-05-03T04:34:36Z

Vinipsmaker:

User:Vinipsmaker/GSoC13/Proposal

2013-05-02T03:42:46Z

Vinipsmaker: /* 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? */

= Proposal =

TODO

= Questionnaire =
== 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on? ==

I choose the Addon Server project.

== 4.3) Why did you choose this project? ==

I like to program code that will use networking capatibilities.

== 4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then". ==

TODO

== 4.5) Include as much technical detail about your implementation as you can ==

TODO

== 4.6) What do you expect to gain from this project? ==

I intend to gain a lot of fun developing in C++ for a famous open source game.

== 4.7) What would make you stay in the Wesnoth community after the conclusion of SOC? ==

github, C++11, good development infrastructure, generic reusable subprojects, ... (this list is an OR and it's incomplete... a lot of things can motivate me)

User:Vinipsmaker/GSoC13/Questionnaire

2013-05-02T03:31:20Z

Vinipsmaker: /* 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

My forum's username is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

I worked on a lot of projects. Among them:

* A very very simple enrollment system built on top of [http://nodejs.org/ Node.js asynchronous web frameowork for JavaScript]
* A bomberman-like networked Qt-game (it lacks several things I'm planning to release in a refactored version)
* I've worked on a private GStreamer plugin in C

Projects cited below aren't repeated here.

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I fixed [https://gna.org/bugs/?20765 a bug within Wesnoth] and I'm waiting for the [https://github.com/wesnoth/wesnoth-old/pull/3 fix to being merged].

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* The first time a took a look at '''WML''' was this week, but this format reuses several patterns found in languages that I'm used to, such as preprocessor-like features from C, variables and expressions ressembling a bit of bash, the overall structure being a combination of INI and XML.
* My experience with '''Lua''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript, Java and MongoDB.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

User:Vinipsmaker/GSoC13/Questionnaire

2013-05-02T03:30:36Z

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

My forum's username is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

I worked on a lot of projects. Among them:

* A very very simple enrollment system built on top of [http://nodejs.org/ Node.js asynchronous web frameowork for JavaScript]
* A bomberman-like networked Qt-game (it lacks several things I'm planning to release in a refactored version)
* I've worked on a private GStreamer plugin in C

Projects cited below aren't repeated here.

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I fixed [a bug within Wesnoth](https://gna.org/bugs/?20765) and I'm waiting for the [fix to being merged](https://github.com/wesnoth/wesnoth-old/pull/3).

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* The first time a took a look at '''WML''' was this week, but this format reuses several patterns found in languages that I'm used to, such as preprocessor-like features from C, variables and expressions ressembling a bit of bash, the overall structure being a combination of INI and XML.
* My experience with '''Lua''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript, Java and MongoDB.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

User:Vinipsmaker/GSoC13/Questionnaire

2013-05-01T05:51:53Z

Vinipsmaker: /* 5.1) Are you familiar with any of the following tools or languages? */

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

My forum's username is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

I worked on a lot of projects. Among them:

* A very very simple enrollment system built on top of [http://nodejs.org/ Node.js asynchronous web frameowork for JavaScript]
* A bomberman-like networked Qt-game (it lacks several things I'm planning to release in a refactored version)
* I've worked on a private GStreamer plugin in C

Projects cited below aren't repeated here.

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I didn't send any patches to Wesnoth (yet!). I hope this will change soon.

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* The first time a took a look at '''WML''' was this week, but this format reuses several patterns found in languages that I'm used to, such as preprocessor-like features from C, variables and expressions ressembling a bit of bash, the overall structure being a combination of INI and XML.
* My experience with '''Lua''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript, Java and MongoDB.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

ConditionalActionsWML

2013-05-01T04:15:42Z

Vinipsmaker:

{{WML Tags}}

Part of [[ActionWML]], Conditional Actions WML is used to describe container actions that create branching and flow control for WML. The [[#Conditional Actions|conditional actions]] act as gatekeepers, encapsulating other actions with [[#Condition Tags|conditions]] which must be met before an action can take place. These conditional actions also contain the actions which will take place if those conditions are met and, in some cases, what actions will take place if they are ''not'' met.

== Conditional Actions ==

These actions describe actions that should be executed only if certain conditions are met.

=== [if] ===

Executes actions only if the contained [[#Condition Tags|conditions]] are met.

* [[#Condition Tags|Condition Tags]]: Conditions which must be met for the actions in the '''[then]''' tag to be executed.

* '''[then]''': Contains [[ActionWML|actions]] which should be executed if all conditions evaluate as true ''or'' if any single '''[or]''' tag evaluates as true.

* '''[else]''': Contains [[ActionWML|actions]] which should be executed if any condition evaluates as false ''and'' '''all''' of the '''[or]''' tags evaluate as false.

'''Attention''': There are tags named [if] and [else] inside [animation] (see [[AnimationWML#.5Bif.5D_and_.5Belse.5D|AnimationWML]]), which have a different syntax.

Example usage:
[if]
[variable]
name=we.gold
greater_than=$they.gold
[/variable]
[then]
[message]
message=This should be easy!
[/message]
[/then]
[else]
[message]
message=This will not be easy!
[/message]
[/else]
[/if]

=== [switch] ===

The '''[switch]''' tag is a special case because it does not use [[#Condition Tags|Condition Tags]] to control whether actions are performed. Instead, it executes different sets of actions based on the value of a variable.

* '''variable''': The name of the variable to check.
* '''[case]''': Case tag which forms a block containing:
** '''value''': The value to test the variable's value against.
This can be a comma separated list of values.
** [[ActionWML|Action WML]]: Action WML to execute if the variable matches the value. (The rest of the '''[case]''' block after the '''value''' attribute.)
* '''[else]''': Else tag which forms a block of [[ActionWML|Action WML]] to execute if no '''[case]''' block contains a '''value''' matching the value of the '''variable'''.

Example usage:
[switch]
variable=foo
[case]
value="A"
... WML if foo=A ...
[/case]
[case]
value="B"
... WML if foo=B ...
[/case]
[else]
... WML if not foo=A nor foo=B ...
[/else]
[/switch]

=== [while] ===

Like the '''[if]''' tag, executes actions only if conditions described in the contained [[#Condition Tags|conditions]] are met. Additionally, the '''[while]''' tag ''continues'' to execute the actions until the contained [[#Condition Tags|conditions]] are no longer met. Executes a maximum of 65536 iterations per invocation.

* [[#Condition Tags|Condition Tags]]: Conditions which must be met for the actions in the '''[do]''' tag to be executed.

* '''[do]''': contains [[ActionWML|actions]] that should be executed repeatedly until some condition is false.

The '''[while]''' tag is useful for iterating over an array.
An array is a list of values.
The ''number''th value in the array '''array''' is stored in the WML variable '''''array''[number]'''.
Note that if '''number''' is the value of the variable '''variable''',
the expression '''$''array''[$variable]''' will return the ''number''th value in ''array''.

==== 'FOREACH' Macro ====
This macro simplifies the use of a '''[while]''' tag to create a ''for-each'' iteration format. This is useful, for example, when you want to iterate over each row in a table. To use it, use the [http://www.wesnoth.org/macro-reference.xhtml#FOREACH FOREACH] and [http://www.wesnoth.org/macro-reference.xhtml#NEXT NEXT] macros.

==== 'REPEAT' Macro ====
This macro simplifies the use of a '''[while]''' tag to execute the same [[ActionWML|actions]] repeatedly for a specified number of times. To use it, use the [http://www.wesnoth.org/macro-reference.xhtml#REPEAT REPEAT] macro.

=== [command] ===

This tag is more of an Unconditional Action: when it is encountered, the [[ActionWML|actions]] in its content are simply executed once. In practice, this tag serves little purpose. However, it may be used to arrange actions together in logical groups, for example, with actions that are stored in an array and later inserted.
(It is also used inside of [set_menu_item] and [option] of [[InterfaceActionsWML]].)

== Condition Tags ==

===True Condition Tags===
These tags describe conditions which must be met before an action can take place. Some or all of them are used in the various [[#Conditional Actions|Conditional Actions]].

; [have_unit]
: A unit with greater than zero hit points matching this filter exists.
:* [[StandardUnitFilter]] '''*''': Selection criteria. Do not use a [filter] tag.
:* '''count''': ''(Optional)'' If used, a number of units equal to the value must match the filter. Accepts a number, range, or comma separated range. If not used, the default value is "1-99999".
:* '''search_recall_list''': ''(Optional)'' If 'yes', search through recall list too. (Default is 'no')

; [have_location]
: A location matching this filter exists.
:* [[StandardLocationFilter]]: Selection criteria.
:* '''count''': ''(Optional)'' If used, a number of locations equal to the value must match the filter. Accepts a number, range, or comma separated range. If not used, the default value is "1-99999".

; [variable]
: Test the value of a WML [[VariablesWML|variable]] against another value.
:* '''name''': The name of the variable to test.
:* ''<comparison>'': '''One''' of the following keys must be used to compare the value of the named variable, represented as ''$name'' below, against another value:
:** '''contains''': ''$name'' contains this string value.
:** '''equals''': ''$name'' is equal (string wise) to this value.
:** '''not_equals''': ''$name'' is not equal (string wise) to this value.
:** '''numerical_equals''': ''$name'' is equal (numerically) to this value.
:** '''numerical_not_equals''': ''$name'' is not equal (numerically) to this value. '''*''' '''*''' Using equals is faster. The point of numerical_equals and boolean_equals is not performance, it's representation. For instance, "1" and "1.0" are not equal as strings but they are equal as numbers; and "yes" and "true" are not equal as strings but they are equal as booleans. (This also explains why equals is faster: it is a straightforward comparison that doesn't try to understand what you have written.)
:** '''greater_than''': ''$name'' is greater than this value.
:** '''greater_than_equal_to''': ''$name'' is greater than or equal to this value.
:** '''less_than''': ''$name'' is less than this value.
:** '''less_than_equal_to''': ''$name'' is less than or equal to this value.
:** '''boolean_equals''': ''$name'' has an equivalent boolean value. '''*'''
:** '''boolean_not_equals''': ''$name'' does not have an equivalent boolean value. '''*'''
====Boolean Values====
When values are evaluated as boolean values they are checked to see if they are ''false'' or ''true''.

* These values are evaluated as ''true'': '''"yes"''' and '''"true"'''
* These values are evaluated as ''false'': '''"no"''', '''"false"''' and '''""'''(uninitialized)
** However, in contexts where ''true'' is defined as the default value, an uninitialized value would be considered true.

'''Warning:''' Do not use "off", "on", integers, floating-point numbers or anything else than the above as booleans.

=== Meta-Condition Tags ===

These tags aren't really conditions, themselves. Instead they are wrapped around condition tags to group them into multiple conditions that must all be met, lists of conditions that only one must be met, or conditions that must not be met. These are handled in top-to-bottom order in any combination you can think of. One important thing to remember is if you are using '''[or]''' tags, the first conditional statement should ''not'' have an '''[or]''' tag wrapped around it.

; [and]
: A condition which must evaluate to true in addition to any other conditions that precede it. This is useful as a bracket for complex conditions, but not strictly necessary.
:* [[#Condition Tags|Condition Tags]]: If these evaluate to true, the '''[and]''' tag evaluates to true.

; [or]
: A condition which, when false, has no effect, but when true, allows previously failed conditions to be ignored.
:* [[#Condition Tags|Condition Tags]]: If these evaluate to true, the '''[or]''' tag evaluates to true.

; [not]
: Similar to [and], but its contents must be false. Thus it reverses the evaluation of its contents. Since a normal condition tag without contents is always considered true, an empty [not] is always considered false.
:* [[#Condition Tags|Condition Tags]]: If these evaluate to true, the '''[not]''' tag evaluates to false. If these evaluate to false, the '''[not]''' tag evaluates to true.

When multiple meta-conditions are encountered one after another in a containing tag, the evaluation order is as follows:
# the immediate contents of the containing tag are evaluated first to determine if there is a successful match known as a "true" condition
# this true or false result is combined with the top meta-condition to produce another true or false result
# this result is combined with the next meta-condition, and so on. However, if the engine recognizes that no remaining meta-conditions might reverse the result, it will cleverly skip them.
# if the final result is a successful match, then the [[:Category:ActionsWML|action]] will take place.

For more details on use of meta-conditions, see [[AdvancedConditionalWML|these examples]].

== See Also ==
* [[VariablesWML]]
* [[InternalActionsWML]]
* [[DirectActionsWML]]
* [[InterfaceActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]
[[Category: ActionsWML]]

User:Vinipsmaker/GSoC13/Questionnaire

2013-04-28T19:19:54Z

Vinipsmaker: /* 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? */

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

My forum's username is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

I worked on a lot of projects. Among them:

* A very very simple enrollment system built on top of [http://nodejs.org/ Node.js asynchronous web frameowork for JavaScript]
* A bomberman-like networked Qt-game (it lacks several things I'm planning to release in a refactored version)
* I've worked on a private GStreamer plugin in C

Projects cited below aren't repeated here.

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I didn't send any patches to Wesnoth (yet!). I hope this will change soon.

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* My experience with '''Lua''' and '''WML''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript, Java and MongoDB.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

User:Vinipsmaker/GSoC13

2013-04-28T04:08:36Z

Vinipsmaker:

{{SoC2013Student}}

You can see my [[/Proposal]] and my [[/Questionnaire]]'s answers.

User:Vinipsmaker/GSoC13/Questionnaire

2013-04-28T04:02:02Z

Vinipsmaker:

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

I worked on a lot of projects. Among them:

* A very very simple enrollment system built on top of [http://nodejs.org/ Node.js asynchronous web frameowork for JavaScript]
* A bomberman-like networked Qt-game (it lacks several things I'm planning to release in a refactored version)
* I've worked on a private GStreamer plugin in C

Projects cited below aren't repeated here.

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I didn't send any patches to Wesnoth (yet!). I hope this will change soon.

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* My experience with '''Lua''' and '''WML''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript, Java and MongoDB.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

User:Vinipsmaker/GSoC13/Proposal

2013-04-28T03:59:30Z

Vinipsmaker: Created page with '= Proposal = TODO = Questionnaire = == 4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate…'

User:Vinipsmaker/GSoC13/Questionnaire

2013-04-28T03:43:00Z

Vinipsmaker:

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

I worked on a lot of projects. Among them:

* A very very simple enrollment system built on top of [http://nodejs.org/ Node.js asynchronous web frameowork for JavaScript]
* A bomberman-like networked Qt-game (it lacks several things I'm planning to release in a refactored version)
* I've worked on a private GStreamer plugin in C

Projects cited below aren't repeated here.

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I didn't send any patches to Wesnoth (yet!). I hope this will change soon.

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* My experience with '''Lua''' and '''WML''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript and Java.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

User:Vinipsmaker/GSoC13/Questionnaire

2013-04-28T03:35:52Z

Vinipsmaker: Created page with '= 1) Basics = == 1.1) Write a small introduction to yourself. == I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wor…'

= 1) Basics =

== 1.1) Write a small introduction to yourself. ==

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

== 1.2) State your preferred email address. ==

vini.ipsmaker<at>gmail<dot>com

== 1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it? ==

My IRC's nickname is ''vinipsmaker''.

== 1.4) Why do you want to participate in summer of code? ==

I love to develop and I think GSoC is an excellent initiative.

== 1.5) What are you studying, subject, level and school? ==

I'm majoring in computer science at Universidade Federal de Alagoas.

== 1.6) What country are you from, at what time are you most likely to be able to join IRC? ==

I'm from Brazil and I'm able to join IRC from 22:30 till 3:00 everyday, but I join IRC as soon as I connect to the internet and I'll probably be online from 17:00 till 4:00 (GMT time).

== 1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when. ==

I'll have 4h/day 3d/week classes.

= 2) Experience =

== 2.1) What programs/software have you worked on before? ==

== 2.2) Have you developed software in a team environment before? ==

I worked on some team projects before. Among other projects, I worked on:

* [https://code.google.com/p/ntouche/ An unfinished hypermedia diagramming tool for mobile]
* [http://brisa.garage.maemo.org/ An UPnP framework]

== 2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why? ==

I never participated on Google Summer of Code before.

== 2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement. ==

I'm the lead developer of [https://github.com/vinipsmaker/tufao an asynchronous web framework for C++ built on top of Qt] and I'm the brazilian's translation maintainer for the [http://enlightenment.org/ Enlightenment project].

== 2.5) Gaming experience - Are you a gamer? ==

Yes, I'm a gamer.

== 2.5.1) What type of gamer are you? ==

I'm the type of gamer that like games that:
* Run on GNU/Linux
* Console games (preferably portable)

== 2.5.2) What type of games? ==

I like strategy games (like Wesnoth), Action-RPG games (like The Legend of Zelda) and dumb games (like mines and gnujump).

== 2.5.3) What type of opponents do you prefer? ==

I like to play against AI or against my AFK friends.

== 2.5.4) Are you more interested in story or gameplay? ==

Gameplay.

== 2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer. ==

I finished some campaigns on single-player mode, but I avoid multiplayer-mode, because I always lose (shame on me).

== 2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so. ==

I didn't send any patches to Wesnoth (yet!). I hope this will change soon.

= 3) Communication skills =

== 3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English. ==

I write some english posts on my [http://vinipsmaker.wordpress.com/category/en/ blog] and you can see the [http://vinipsmaker.github.io/tufao/ref/1.x/ Tufão documentation] (both written by myself).

== 3.2) What spoken languages are you fluent in? ==

I can watch and understand videos about C++ (Bjarne Stroustroup, Herb Sutter, Andrei Alexandrescu, ...), but I never practice, so I must be terrible speaking.

I'm fluent in brazilian portuguese.

== 3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough. ==

Yes.

== 3.4) Do you give constructive advice? ==

Yes.

== 3.5) Do you receive advice well? ==

Yes.

== 3.6) Are you good at sorting useful criticisms from useless ones? ==

Usually not.

== 3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want ==

I tend to not wait for other people.

If I face a surprising situation where I have more than one choice and each choice have its drawbacks, I'll document the choices and send this documentation to the other developers as a starting pointing to choose the solution.

I like to allow my colleagues track my progress also.

= 4) Project =

See my [[../Proposal]].

= 5) Practical considerations =

== 5.1) Are you familiar with any of the following tools or languages? ==

* I'm familiar with the '''C++ programming language''' and the '''STL''' templates library. C++ is my programming language of choice for a long time already. I just need to master all the power of templates-machinery and I'll be happier yet.
* I never used '''Boost''', but I follow the Boost project and read the documentation of some pieces from time to time.
* I used '''SDL''' long time ago in a [https://code.google.com/p/eater-thief/ small game] for my first programming's classes. At the time, I didn't understand asynchronous/event-based-programming and other concepts very well and I was only an amateur at threading programming.
* I love '''Python'''<nowiki>'</nowiki>s expressiveness power, but I never read a full programming book about it, so I don't even know what I don't know about the language. You can see [https://code.google.com/p/logica-whopper/ my last Python's project at googlecode].
* I'm familiar with '''cmake''' and I use it in some projects, but I never read a single line of code of '''scons'''.
* I'm familiar with '''Git''' (see my [https://github.com/vinipsmaker GitHub profile], for instance) version control system
* My experience with '''Lua''' and '''WML''' is near to zero, but I don't think this would be a problem. Learn a new language is easy. Learn a new programming paradigm is hard.

== 5.2) Which tools do you normally use for development? Why do you use them? ==

* I use '''Emacs''' editor, because it's an advanced text editor with support for multiple languages. IDEs are usually much intrusive and I don't like intrusive tools, so I just use Emacs. You can see my [https://code.google.com/p/vinipsmaker/source/browse/config/.emacs Emacs config here].
* '''LLVM/Clang''' compiler, because the colored output. But most of the time I'm using '''GCC'''.
* '''CMake''' build system, because it's fast (compared to autotools, at least on my machine), it's easy and has a build's progress status.
* '''git''' version control system, because has a lot of integrated features (branching easier and more powerful than in subversion, at least with the knowledge that I have).
* '''Meld diff tool''', because it has a nice GUI.
* '''Doxygen''' for documentation, because it's the best.
* ''C++''' programming language, because of control and expressiveness power (not as much as Python, but still better than Java).
* Any drop-down terminal (currently '''Terra''') with good support for tabs.
* Any rolling-release distro that do not separate packages in normal and “-dev”. Currently '''ArchLinux'''.

== 5.3) What programming languages are you fluent in? ==

I'm fluent in C, C++, JavaScript and Java.

== 5.4) Would you mind talking with your mentor on telephone / internet phone? ==

I have an skype account, but you can always reach me via email (I read it daily/hourly/minutely).

I can provide my phone number.

User:Vinipsmaker/GSoC13

2013-04-28T01:55:28Z

Vinipsmaker:

You can see my [[/Proposal]] and my [[/Questionnaire]]'s answers.

User:Vinipsmaker/GSoC13

2013-04-28T01:55:05Z

Vinipsmaker: Created page with 'You can see my [/Proposal] and my [/Questionnaire]'s answers.'

You can see my [/Proposal] and my [/Questionnaire]'s answers.

User:Vinipsmaker

2013-04-28T01:49:32Z

Vinipsmaker: /* Vinipsmaker */

= Vinipsmaker =

I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates to me (github user, lastfm profile, ...), [https://about.me/vinipsmaker click here].

My nickname on IRC is vinipsmaker.

== Google Summer of Code 2013 ==

[[/GSoC13]]

User:Vinipsmaker

2013-04-28T01:47:44Z

Vinipsmaker: Created page with '= Vinipsmaker = I'm an ArchLinux user that likes C++. You can see my blog at [http://vinipsmaker.wordpress.com/category/en/ wordpress]. If you want to see all links that relates…'