User:Vinipsmaker/GSoC13/Proposal - Revision history

Vultraz: Dropped link to BinaryWML

2015-04-22T06:51:14Z

Dropped link to BinaryWML

Vinipsmaker: /* Timeline */

2013-05-20T19:29:08Z

‎Timeline

Vinipsmaker: /* Timeline */

2013-05-19T22:52:02Z

‎Timeline

Vinipsmaker: /* Timeline */

2013-05-19T22:41:04Z

‎Timeline

Vinipsmaker: fix small gramar issue

2013-05-19T20:58:15Z

fix small gramar issue

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

2013-05-19T20:11:45Z

‎Event loop != boost::io_service

Vinipsmaker: /* Timeline */

2013-05-19T20:03:55Z

‎Timeline

Vinipsmaker: timeline: convert from list to table

2013-05-19T19:02:25Z

timeline: convert from list to table

Vinipsmaker at 20:49, 17 May 2013

2013-05-17T20:49:57Z

Vinipsmaker at 05:30, 9 May 2013

2013-05-09T05:30:35Z

Show changes

@@ Line 119: / Line 119: @@
 === 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.
+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.'''

@@ Line 196: / Line 196: @@
 * Documentation should follow it progress.
 |-
-| Week 8 (July 14 to 20) || Introduce threads and SSL. || Mandatory for threads and optional for SSL ||
+| Week 8 (July 14 to 20) || Introduce threads || Mandatory ||
 |-
 | 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)

@@ Line 178: / Line 178: @@
 |-
 | Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server.
-| style="background: #00FF00;" | DONE
+| bgcolor="#00FF00" | DONE
 || Debian 6.0 (squeeze) with [http://wiki.wesnoth.org/CompilingWesnoth#Prerequisites all Wesnoth build deps] (tested)
 |-

@@ Line 177: / Line 177: @@
 ! Period !! Task !! Status !! Notes
 |-
-| Week -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server. || Mandatory ||
+| 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. || Mandatory ||

@@ Line 184: / Line 184: @@
 |-
 | 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
+* This feature will depend on the event loop
 * It'll delegate the '''read''' operations to the database
 |-

@@ Line 69: / Line 69: @@
 === 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].
+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.

@@ Line 181: / Line 181: @@
 | 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 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 the current protocol in Boost.asio. || Mandatory ||
+| Week 3 (June 9 to 15) || Reimplement a subset of the current protocol in Boost.asio. || Optional ||
 |-
-| Week 4 (June 16 to 22) || Start working on the authentication support. || Mandatory ||
+| 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 || Documentation should follow it progress.
+| Week 5-7 (June 23 till July 13) || Implement the new protocol || Mandatory ||
 |-
-| Week 8 (July 14 to 20) || Introduce threads and SSL. || Mandatory ||
+| 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 ||
+| 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 ||

@@ Line 173: / Line 173: @@
 == Timeline ==
-* Week -1 (May 12 to 18): Install a Debian chroot in my system that mimics Wesnoth main server. ''(mandatory)''
+{| class="wikitable"
-* 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)''
+! Period !! Task !! Status !! Notes
-* 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 -1 (May 12 to 18) || Install a Debian chroot in my system that mimics Wesnoth main server. || 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 0 (May 19 to 25) || Create a Wesnoth branch and start coding. Get used to Boost.asio. || 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 1-2 (May 26 till June 8) || Create the SimpleAddonManager, capable of execute the operations needed to manage add-ons. || 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.

@@ Line 25: / Line 25: @@
 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.
+=== The WML-based database ===
 A migration script will be provided to convert the add-ons from the previous format to the new one.
@@ Line 36: / Line 40: @@
 * 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 ==
@@ Line 54: / Line 62: @@
 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.
 === Config files ===
@@ Line 69: / Line 84: @@
 *** 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.
+** database: It may contain several child tags to configure what database to use. The database data and configuration are kept in separate.
 ** Port: Which port it would use
 ** SSL: Settings related to SSL (key file, key file password, server port, ...)
-=== SimpleAddonManager Filesystem layout ===
+=== SimpleAddonManager ''(WML-based database)'' Filesystem layout ===
 The SimpleAddonManager would save the add-ons using the following schema:
@@ Line 79: / Line 95: @@
 * ''/'': 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.
+** ''journal.log'': It will provide basic guarantees to avoid severe data loss (see below).
 ** ''Add-ons/''
 *** ''Add-on name/''
@@ Line 86: / Line 102: @@
 ***** ''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 ==
@@ Line 99: / Line 121: @@
 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.
+* 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.
@@ Line 138: / Line 160: @@
 ** ''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 -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
+* 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.
+* 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.
+* 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
+* 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).
+* 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
+* Week 8 (July 14 to 20): Introduce threads and SSL ''(mandatory)''
-* Week 9-11 (July 21 till August 10): LDAP support
+* 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
+* 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
+* Week 13-16 (August 18 till September 14): Integrate the new protocol in Wesnoth client ''(mandatory)''
 = Questionnaire =