Difference between revisions of "User:Vinipsmaker/GSoC13/Proposal"

From The Battle for Wesnoth Wiki
(Better localization and internationalization support)
(Better localization and internationalization support)
Line 39: Line 39:
 
The translations are developed/maintained at [https://github.com/wescamp github] under multiple repositories of a single organization (but not all repositories are translations).
 
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 depends on older tools make this challenge still more difficult. To improve this scenario, the proposed addon server should host the translations itself. The solution must be easy to use to please the translators.
+
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 solution must be easy to use to please the translators.
  
 
I'll add more detail about the solution very soon.
 
I'll add more detail about the solution very soon.

Revision as of 05:34, 6 May 2013

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 boost.asio to deliver better performance (you can see a good in-depth look at the problem of handling tons of clients at [1])
    • Better performance scalability are the main objectives of this proposal
  • Use RAII extensively to provide good support for excepetions 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

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.

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.

Each campaign would continue to be stored in files exactly how it's done now, so a transition to the new server wouldn't affect the current addons database.

Better metadata support

Currently the addon is saved in the disk with few modifications, but the metadata used is fixed an 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 script is run by hand every time the translations need to be updated.

The translations are developed/maintained at 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 solution must be easy to use to please the translators.

I'll add more detail about the solution very soon.

Architecture

The server would be built on top of 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:

architecture.png

The session component might implement multiple protocols and would be further broken down.

Timeline

Before the chosen students are announced (during the month of may), I'd finish the architecture draft and the new protocol spec and install an Debian chroot in my system that mimics Wesnoth main server. I may interact more with Wesnoth developers in this phase.

I'd finish the initial components (the addon manager, the event loop and a functional session handling) before july 20. After that, I'd introduce threads (which should be ready in one week). Then I'd introduce and implement the several authentication mechanisms. I have less experience with LDAP (only as a sysadmin at LCCV for a while) and would take more time to implement it.

Every thing should be finished by the first week of september.

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)