SoC2012 Ivan Addon Server - Revision history

Esr: Hide historical references to Subversion from the wiki search function

2013-03-21T01:01:44Z

Hide historical references to Subversion from the wiki search function

← Older revision		Revision as of 01:01, 21 March 2013
Line 5:		Line 5:
	<h4>Ivan Savenko - Addon Server</h4>		<h4>Ivan Savenko - Addon Server</h4>
	The goal of this project is to write a new add-on server for Wesnoth from scratch.		The goal of this project is to write a new add-on server for Wesnoth from scratch.
	Original draft in ~~SVN~~ (latex): http://svn.gna.org/viewcvs/wesnoth/trunk/doc/design/		Original draft in SVN (latex): http://svn.gna.org/viewcvs/wesnoth/trunk/doc/design/

	Will be written in C++, networking part - boost::asio. From existing codebase I'm going to use WML parser (class "config") and forum integration (class "fuh" aka "forum user handler")		Will be written in C++, networking part - boost::asio. From existing codebase I'm going to use WML parser (class "config") and forum integration (class "fuh" aka "forum user handler")
Line 257:		Line 257:

	=== Are you familiar with any of the following tools or languages? ===		=== Are you familiar with any of the following tools or languages? ===
	* ~~Subversion~~ - basic commit\checkout via GUI		* Subversion - basic commit\checkout via GUI
	* C++ and STL - good I think. Have been actively using it for at least 2 years.		* C++ and STL - good I think. Have been actively using it for at least 2 years.
	* Boost - I've used several libraries (filesystem, functions, algorithms...), but not asio		* Boost - I've used several libraries (filesystem, functions, algorithms...), but not asio

IvanS: /* Storage */

2012-04-11T14:06:46Z

Storage

← Older revision		Revision as of 14:06, 11 April 2012
Line 17:		Line 17:
	==Storage==		==Storage==
	Main file - umcd.cfg. Read-only, should be passed as 1st parameter on launch:		Main file - umcd.cfg. Read-only, should be passed as 1st parameter on launch:
			<pre>
	[settings]		[settings]
	port = 15002		port = 15002
Line 23:		Line 24:
	...		...
	[/settings]		[/settings]
			</pre>
	(Optional) this file may have multiple sections for each major version of Wesnoth. In this case umcd will automatically start separate copy for each section in this file.		(Optional) this file may have multiple sections for each major version of Wesnoth. In this case umcd will automatically start separate copy for each section in this file.

	All umcd files will be locate in storage_path:		All umcd files will be locate in storage_path:
	storage.cfg - stores current state of server (like config of all uploaded mods)		* storage.cfg - stores current state of server (like config of all uploaded mods)
	archives/ - directory with archives of all add-ons (similar to http://files.wesnoth.org/addons/1.9/)		* archives/ - directory with archives of all add-ons (similar to http://files.wesnoth.org/addons/1.9/)
	unpacked/ - unpacked version of mods for validation and wescamp integration (similar to http://files.wesnoth.org/addons/1.9/unpacked/)		* unpacked/ - unpacked version of mods for validation and wescamp integration (similar to http://files.wesnoth.org/addons/1.9/unpacked/)

	==PBL specification==		==PBL specification==
	* Old directory structure won't be supported - _addon.pbl and _main.cfg must be placed in add-on subdirectory (only 5 add-ons on 1.9 server still use it)		* Old directory structure won't be supported - _addon.pbl and _main.cfg must be placed in add-on subdirectory (only 5 add-ons on 1.9 server still use it)

IvanS at 14:05, 11 April 2012

2012-04-11T14:05:07Z

← Older revision		Revision as of 14:05, 11 April 2012
Line 15:		Line 15:

	=Detailed proposition=		=Detailed proposition=
			==Storage==
			Main file - umcd.cfg. Read-only, should be passed as 1st parameter on launch:
			[settings]
			port = 15002
			threads_count = 4
			storage_path = /var/umcd-1.10/
			...
			[/settings]
			(Optional) this file may have multiple sections for each major version of Wesnoth. In this case umcd will automatically start separate copy for each section in this file.
			All umcd files will be locate in storage_path:
			storage.cfg - stores current state of server (like config of all uploaded mods)
			archives/ - directory with archives of all add-ons (similar to http://files.wesnoth.org/addons/1.9/)
			unpacked/ - unpacked version of mods for validation and wescamp integration (similar to http://files.wesnoth.org/addons/1.9/unpacked/)
			==PBL specification==
			* Old directory structure won't be supported - _addon.pbl and _main.cfg must be placed in add-on subdirectory (only 5 add-ons on 1.9 server still use it)
			* Add to PBL field "status". Set by author (Complete, Testing, Incomplete, Unusable). User should be able to see this field and select addons with required level of completeness. (Optional) Allow uploading several add-ons with same name but different status so add-on may have "stable" releases along with "development" ones.
			** Complete - addon is complete, has no major bugs.
			** Testing - addon is complete but have some bugs.
			** Incomplete - addon is still work-in-progrees.
			** Unusable - add-on is for testing purposes and should not be installed by regular user.
			** This field can be set by server to "Broken" in case of any issues like missing dependencies.

	~~==Protocol specification==~~		* Field "uploader" - will be replaced by "uploaders". This is list of valid usernames who can access this add-on.
	* Add to PBL field "status". Set by author (Complete, Beta, Incomplete, Unusable).		* Field "authors" - will be displayed as it, no checks for usernames.
	** Unusable means that add-on is for testing purposes and should not be installed by regular user.
	** This field can be set by server to "Broken" if wmlint will fail (may happen when new version of Wesnoth or prerequisite add-on is out).
	* Field "uploader" - will be replaced by "uploaders" ~~(probably automatically or by wmlint)~~. ~~List~~ of usernames who can access this add-on~~, username must be valid~~
	* Field "authors" - will be displayed as it, no checks for ~~username validness~~

	==Users authentication==		==Users authentication==
	This will remove any need to store ~~password~~ or e-mail in PBL and will make contacting author by administration easier (PM on forum or e-mail).		This will remove any need to store passphrazes or e-mail in PBL and will make contacting author by administration easier (PM on forum or e-mail).

	Unregistered users - ~~needs discussion, easiest way is~~ to ~~disable uploading for~~ unregistered users. Reasoning: even basic e-mail confirmation (as proposed by shadowm) is almost identical what we have at forum.wesnoth.org but will require notable amount of work.		Unregistered users - It should be possible to keep current passphrazes system which will be used if PBL have "passphraze" field intead of new "uploaders"
			Uploading by unregistered users should be selectable via server confug file. Reasoning: even basic e-mail confirmation (as proposed by shadowm) is almost identical what we have at forum.wesnoth.org but will require notable amount of work. Most of UMC authors have account anyway. I found ~20 UMC authors (out of ~200) with add-ons on 1.8 server that don't have account with exactly same username, most of which are typos or a bit different username.
	Most of UMC authors have account anyway. I found ~20 UMC authors with add-ons on 1.8 server that don't have account with exactly same username, most of which are typos or a bit different username.

	~~Behaviour will be similar to multiplayer server~~.

			Code-wise behaviour will be similar to multiplayer server.
			UI behaviour - after user uploaded correct PBL he will be asked for username\password (same dialog as in multiplayer server)
	==Add-ons updating==		==Add-ons updating==
	Server will keep history in this format:		Server will keep history in this format:
	<pre>		<pre>
	[update]		[update]
	"uploader" = username of person who uploaded this version		"uploader" = username of person who uploaded this version (if non-anonymous upload)
	"timestamp" = unix timestamp of upload		"timestamp" = unix timestamp of upload
	"ip_address" = ip address of uploader		"ip_address" = ip address of uploader
Line 66:		Line 82:
	* "conflicts" - only one add-on of these two can be installed.		* "conflicts" - only one add-on of these two can be installed.
	* "recommends" - add-on have non-essential content that will be used by this one		* "recommends" - add-on have non-essential content that will be used by this one

			==Concurrency==
			Several days ago I've encontered interesting issue with current campaign server - it is possible to download add-on which is currently being updated by author. This resulted in several GUI issues and finally - crash (no stacktrace unfortunately). This means that new add-on server should support atomic updates to prevent such issues.

			==Client-side changes==
			I'll try to keep is as it during GSoC. Change in displayed columns may be the biggest change in UI (e.g I'm going to replace download counts with date of last update)

	== Timeline ==		== Timeline ==
	Note: Most possibly I'll be free for 1-2 weeks in May - still don't have my exams schedule. Will shift timeline as soon as I will know ~~the schedule~~.		Note: Most possibly I'll be free for 1-2 weeks in May - still don't have my exams schedule. Will shift timeline as soon as I will know it. Current "definitely free" date is May, 28
	=== Summer of code timeline ===		=== Summer of code timeline ===
	{\| border="1"		{\| border="1"
Line 81:		Line 103:
	\| Server		\| Server
	\| June, week 1		\| June, week 1
	\| ~~Create basic server capable of receiving\sending WML.~~ Implement server-side storage~~. Will be partially done as proof-of-concept~~.		\| Implement server-side storage.
	\|-		\|-
	\| Server		\| Server
Line 115:		Line 137:
	* Any tasks not finished during SoC		* Any tasks not finished during SoC
	====Server-side improvements====		====Server-side improvements====
	* wmlint support		* wmlint support - nice to have but not reliable.
	====Client-side improvements====		====Client-side improvements====
	* Send add-on icons to client, probably with some caching. Reasoning: Currently some add-ons use icons from resources of not-yet-installed add-on. Estimated length: 1 week.		* Send add-on icons to client, probably with some caching. Reasoning: Currently some add-ons use icons from resources of not-yet-installed add-on. Estimated length: 1 week.
	* Merge "Remove Add-on" dialog into "Add-ons Manager", add filter "Installed add-ons". Reasoning: not intuitive, for example only way to see installed add-ons is to open "Remove Add-on" dialog. Estimated length: 2 weeks.		* Merge "Remove Add-on" dialog into "Add-ons Manager", add filter "Installed add-ons". Reasoning: not intuitive, for example only way to see installed add-ons is to open "Remove Add-on" dialog. Estimated length: 2+ weeks.
	* Remove "Connect to Server" dialog. Reasoning: selecting add-on server is (completely?) unused. May be kept in configuration file or as command line parameter for those rare cases. Estimated length: 1 week.		* Remove "Connect to Server" dialog. Reasoning: selecting add-on server is (completely?) unused. May be kept in configuration file or as command line parameter for those rare cases. Estimated length: 1 week.
	* Improve "Add-ons Manager" dialog. Will describe this later.		* Improve "Add-ons Manager" dialog. Will describe this later.

IvanS: /* If you have contributed any patches to Wesnoth, please list them below. */

2012-04-06T17:52:13Z

If you have contributed any patches to Wesnoth, please list them below.

← Older revision		Revision as of 17:52, 6 April 2012
Line 179:		Line 179:

	=== If you have contributed any patches to Wesnoth, please list them below. ===		=== If you have contributed any patches to Wesnoth, please list them below. ===
	~~None so far~~.		Proof-of-concept of add-on server: https://gna.org/patch/index.php?3241

	== Communication skills ==		== Communication skills ==

Crab: /* IRC */

2012-03-29T19:20:24Z

IRC

← Older revision		Revision as of 19:20, 29 March 2012
Line 11:		Line 11:
	=IRC=		=IRC=
	IvanSav		IvanSav
			=SoC Application=
			Submitted to google

	=Detailed proposition=		=Detailed proposition=

IvanS: /* Timeline */

2012-03-28T20:04:17Z

Timeline

← Older revision		Revision as of 20:04, 28 March 2012
Line 66:		Line 66:

	== Timeline ==		== Timeline ==
			Note: Most possibly I'll be free for 1-2 weeks in May - still don't have my exams schedule. Will shift timeline as soon as I will know the schedule.
	=== Summer of code timeline ===		=== Summer of code timeline ===
	{\| border="1"		{\| border="1"
Line 77:		Line 78:
	\|-		\|-
	\| Server		\| Server
	\| June, week 1-2		\| June, week 1
	\| Create basic server capable of receiving\sending WML.		\| Create basic server capable of receiving\sending WML. Implement server-side storage. Will be partially done as proof-of-concept.
	\|-		\|-
	\| Server		\| Server
	\| June, week 3		\| June, week 2-3
	\| Add-on upload\download support.		\| Compressing and sending files via network. Add-on upload\download support.
	\|-		\|-
	\| Server, Client		\| Server, Client
	\| June, week 4		\| June, week 3-4
	\| Integration with existing database from forums.		\| Integration with existing database from forums. Will try to re-use current login to multiplayer server dialog.
	\|-		\|-
	\| Server, Client		\| Server, Client
Line 92:		Line 93:
	\| Add-on updating support. Finish any remaining tasks. SoC mid-term evaluation.		\| Add-on updating support. Finish any remaining tasks. SoC mid-term evaluation.
	\|-		\|-
	\| Server		\| Server, Wescamp
	\| July, week 2		\| July, week 2
	\| Implement hooks on server, ~~enable content validation via wmlint~~		\| Implement hooks on server, tool for uploading add-ons on github (based on wescamp.py)
	\|-		\|-
	\| Wescamp		\| Wescamp
	\| July, week 3-4		\| July, week 3-4
	\| Implement ~~tools~~ for receiving translations from github ~~and for uploading add-ons~~ on ~~github~~		\| Implement tool for receiving and compiling translations from github (based on wescamp.py)
	\|-		\|-
	\| ~~Server,~~ Client		\| Client
	\| August, week 1-2		\| August, week 1
	\| Dependencies support		\| Dependencies support. Prerequisites support is already present in client.
	\|-		\|-
	\| General		\| General
Line 109:		Line 110:
	\|}		\|}

	===Possible post-~~GSOC~~ tasks===		===Possible post-SoC tasks===
			* Any tasks not finished during SoC
			====Server-side improvements====
			* wmlint support
	====Client-side improvements====		====Client-side improvements====
	* Send add-on icons to client, probably with some caching. Reasoning: Currently some add-ons use icons from resources of not-yet-installed add-on. Estimated length: 1 week.		* Send add-on icons to client, probably with some caching. Reasoning: Currently some add-ons use icons from resources of not-yet-installed add-on. Estimated length: 1 week.

IvanS: /* What country are you from, at what time are you most likely to be able to join IRC? */

2012-03-27T20:30:45Z

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

← Older revision		Revision as of 20:30, 27 March 2012
Line 136:		Line 136:

	=== What country are you from, at what time are you most likely to be able to join IRC? ===		=== What country are you from, at what time are you most likely to be able to join IRC? ===
	I'm from Ukraine (GMT+2), can be on IRC from ~12:00 GMT and till ~24:00 GMT.		I'm from Ukraine (GMT+3), can be on IRC from ~11:00 GMT and till ~23:00 GMT.

	=== Do you have other commitments for the summer period ? ===		=== Do you have other commitments for the summer period ? ===

IvanS at 18:35, 26 March 2012

2012-03-26T18:35:36Z

Show changes

IvanS at 08:42, 25 March 2012

2012-03-25T08:42:25Z

← Older revision		Revision as of 08:42, 25 March 2012
Line 9:		Line 9:
	Will be written in C++, networking part - boost::asio.		Will be written in C++, networking part - boost::asio.

	=Server=		=Detailed proposition=
			==Protocol==
			* Integration with existing user database from forums (similar to multiplayer server) instead of using separate password for each addon. E-mail for any messages to user can be taken from database as well instead of searate field in pbl
			* Add to PBL field "status". Set by author (Complete, Beta, Incomplete, Unusable).
			** Unusable means that add-on is for testing purposes and should not be installed by regular user.
			** This field can be set by server to "Broken" if wmlint wil fail (may happen when new version of Wesnoth or prerequired add-on is out).

			==Server==
			Should be written mostly from scratch, with using existing WML parser (class "config") and possibly phpbb integration (class "fuh" aka "forum user handler")
	===Essential===		===Essential===
	* Basic upload\download\update functionality.		* Basic upload\download\update functionality.
Line 19:		Line 27:
	This features that can be added anytime, during or after GSoC.		This features that can be added anytime, during or after GSoC.
	* Extend dependencies with "Conflicts" and "Recommends".		* Extend dependencies with "Conflicts" and "Recommends".
	* Integration with existing user database from forums (similar to multiplayer server).
	* Some way to ease bugreporting by players.		* Some way to ease bugreporting by players.
	* Send add-on icons to client? Currently some add-ons use icons from resource of not-yet-installed add-on. Another option is to handle this as error.		* Send add-on icons to client? Currently some add-ons use icons from resource of not-yet-installed add-on. Another option is to handle this as error.

Ejls: Formating

2012-03-22T21:24:00Z

Formating

← Older revision		Revision as of 21:24, 22 March 2012
Line 9:		Line 9:
	Will be written in C++, networking part - boost::asio.		Will be written in C++, networking part - boost::asio.

	==Server==		=Server=
	===Essential===		===Essential===
	* Basic upload\download\update functionality.		* Basic upload\download\update functionality.