Difference between revisions of "AddonServerSocial"
(→Before Summer of code (until May 26)) |
m (→Tags: fix link) |
||
(12 intermediate revisions by 6 users not shown) | |||
Line 48: | Line 48: | ||
Tags can be given by Wesnoth staff and by author. After discussing of it on IRC, users should not have the possibility of adding some tags to addons. By the way, authors can add tags too but NOT the same as those used by the staff. | Tags can be given by Wesnoth staff and by author. After discussing of it on IRC, users should not have the possibility of adding some tags to addons. By the way, authors can add tags too but NOT the same as those used by the staff. | ||
− | There would be 2 types of tags: Registered ones, applied by the admins/staff, and "normal" ones applied by addon's author. Tags used by authors could be set freely or selected in a list defined by the | + | There would be 2 types of tags: Registered ones, applied by the admins/staff, and "normal" ones applied by addon's author. Tags used by authors could be set freely or selected in a list defined by the server's admin. |
Tags permit also to know which addons he liked, and search for addons he WOULD enjoy. It's a simple search function for tags, but it should be appreciated by users. | Tags permit also to know which addons he liked, and search for addons he WOULD enjoy. It's a simple search function for tags, but it should be appreciated by users. | ||
− | Tags would be added in the PBL file for each addon: (Documentation on PBL | + | Tags would be added in the PBL file for each addon: (Documentation on PBL: [[PblWML]]) with the formating (in the _main.cfg, section campaign) : |
authorTags="My First Tag","Cool Addon" | authorTags="My First Tag","Cool Addon" | ||
officialTags="Best Addon Ever" | officialTags="Best Addon Ever" | ||
+ | |||
+ | Tags could be also stored in a unique file for better search capacities. This file would be structured this way: | ||
+ | [tag] | ||
+ | name="my cool tag" | ||
+ | category="author" | ||
+ | addonsId="orcish_incursion", "other_addon" | ||
+ | [/tag] | ||
+ | |||
+ | Every time an addon is uploaded to the campaign server, its tags are selected, and if any match with the authorized tags are found, its id is added to the tag's file. | ||
=== Server Side === | === Server Side === | ||
Line 65: | Line 74: | ||
* Python tools like the WML suite of tools wan be easily usable directly from the server | * Python tools like the WML suite of tools wan be easily usable directly from the server | ||
− | ====Wescamp access via | + | ====Wescamp access via S­­V­­N==== |
2 Solutions seem possible: | 2 Solutions seem possible: | ||
− | * Check the | + | * Check the s­­v­­n every time an user download an addon -> needs to implement the s­­v­­n access directly from the server |
− | * Check the | + | * Check the s­­v­­n on a regular basis -> Simple Cron Job |
− | Documentation on | + | Documentation on s­­v­­n apis in C, C++ and even python found there: http://svnbook.red-bean.com/en/1.1/ch08s02.html |
− | Given this documentation, the simplest solution(except Cron job) to implement is to use | + | Given this documentation, the simplest solution(except Cron job) to implement is to use Sub­­version's Python SWIG bindings (See Examples 8.2 and 8.3). The implementation of these exmaples is far more complicated in C or even C++. By the way, this solution needs one more dependancy. |
=== Client Side === | === Client Side === | ||
Line 101: | Line 110: | ||
Furthermore, an user account creation could be used to track users'data like "addons installed", "languages used...". After discussing of this with Mordante, it would be optional. | Furthermore, an user account creation could be used to track users'data like "addons installed", "languages used...". After discussing of this with Mordante, it would be optional. | ||
+ | ==== Admin UI ==== | ||
+ | Both Wesnoth UI and Web UI should have an admin section, where server's admins can login and get special actions authorized: | ||
+ | |||
+ | * Add official tags. | ||
+ | * Set official tags for addons (add, remove, modify). | ||
+ | * Manage easily addons datas. | ||
+ | Admin Accounts would be stored in a special file: | ||
+ | [account] | ||
+ | id="lao" | ||
+ | password="ikhaiuhaz8U7687654V7YTF8655RFvvhg" #SHA1 encrypted password | ||
+ | name="Lao" | ||
+ | mail="lao.geek@gmail.com" | ||
+ | [/account] | ||
=== Timeline === | === Timeline === | ||
Line 107: | Line 129: | ||
* Work on small bugs/tasks for the Wesnoth Community | * Work on small bugs/tasks for the Wesnoth Community | ||
** Already done a patch for adding commandline options (patch #1031) | ** Already done a patch for adding commandline options (patch #1031) | ||
− | * Understand code used for the addon server/client and wescamp. | + | * Understand code used for the addon server/client, wml tools and wescamp. |
* Being active in the developers community (IRC and forum), specially with mentor(s). | * Being active in the developers community (IRC and forum), specially with mentor(s). | ||
* Clearly design architecture of server-client | * Clearly design architecture of server-client | ||
− | ====Part 1 - server side==== | + | ====Part 1 - server side (1 month)==== |
− | + | * Analysis of changes to be made (4 days) | |
+ | * Refactor server code to integrate s­­v­­n access to wescamp, and use of WML tools. (10 days) | ||
+ | * Add tags support and server-side functionnalities(1week) | ||
+ | * Implement Web interface (1 week) | ||
− | + | ====Part 2 - client side (1 month)==== | |
− | ====Part 2 - client side==== | + | * Gui design/mockups for both Wesnoth and web UI. (2 days) |
+ | * Implement Wesnoth normal client. (9 days) | ||
+ | * Implement Wesnoth admin client. (4 days) | ||
+ | * Implement Web normal client. (9 days) | ||
+ | * Implement Web admin client. (4 days) | ||
====After SoC==== | ====After SoC==== | ||
Line 128: | Line 157: | ||
== Actual Work for Wesnoth == | == Actual Work for Wesnoth == | ||
I've submitted a patch for adding new commandline options, as requested on the [http://www.wesnoth.org/forum/viewtopic.php?f=12&t=20243&p=289988 forum] and [http://www.wesnoth.org/wiki/EasyCoding#Additional_Commandline_Options wiki]. | I've submitted a patch for adding new commandline options, as requested on the [http://www.wesnoth.org/forum/viewtopic.php?f=12&t=20243&p=289988 forum] and [http://www.wesnoth.org/wiki/EasyCoding#Additional_Commandline_Options wiki]. | ||
− | You can found my patch [https://gna.org/patch/index.php?1031 here] | + | You can found my patch [https://gna.org/patch/index.php?1031 here]. |
+ | |||
+ | The patch is now on the s­­v­­n trunk (revision 25325). | ||
Two new options are available with this patch: | Two new options are available with this patch: |
Latest revision as of 03:12, 7 May 2023
Me and Myself
Who Am I IRL ?
My name is Bastien Abadie, I'm french (21), living in Brittany (http://en.wikipedia.org/wiki/Brittany). I'm in an engineering school (http://www.enib.fr), i'll get my master in Computer Science next year.
Actually i work daily on a project for my school about 3D representation of ship and climate conditions of the sea. Plus there is a big network part in this project (connecting a C++ client to a matLab server and using data).
...Online ?
You can contact me by mail or GTalk using lao.geek(at)gmail.com .
My nicknames on Wesnoth are:
- lao on the forum
- La0 on the wiki (lao was already taken :/ )
- lao on gna.org
- Lao on IRC
Experience
Development
I've worked on many websites as a developper (i'm not a design guy !), mostly in PHP, using XHTML/CSS, and sometimes Javascript (with Jquery). Many of my school's projects were made in C/C++ (nethack-like game, HTTP/HTTPS server with cgi server, paint-like ,...); I've played with JAVA (JSF, JQuery for the web, Netbeans ide...) but I rather prefer C++.
Speaking of GUIs, i've made some in Tcl/TK, Qt, and C# but no GTK at the moment. Like most Linux developpers (... and admins) i've made lots of shell scripts, a bit of python,... and played with config files.
Open Source
I'm an occasional developper for ZenPhoto http://zenphoto.org, the simplest and cleanest web photo gallery! I've worked on the video support for ZenPhoto http://la0c00n.info/zenvideo . Now videos are officially supported in the core Zenphoto, no more needs for hacky patches :p I have been very busy at school this year, so little implicated recently in this project.
I have NOT participated in any ways to the Google Summer of Code before.
Games
I'm not a big gamer, but enjoy some good FPS : Half Life 1&2, Portal, Counter Strike (original, not really into Source), all Call of Duty, Serious Sam (only in coop!). I like RPG games as Baldur's Gate, Neverwinter Nights,... I play a bit on my Wii too: Zelda, Super Mario Galaxy, Wario Smooth moves.
Now, for Open Source Games: Lbreakout2, Tremulous, frozen-bubble, ... and Wesnoth of course :)
Practical
As said in my introduction, I live in France, meaning i'm under GMT+1. I can work from 9:30am to 7pm with no problem; i'm generally awaken from 9am to 0AM. I'm used to work late, and attend IRC meetings nightly.
I'have not any exams or school work to do during the period of the SOC. So i won't be pertubated :)
Work on the Addon Server
I plan to work on the Addon Server, update the code to improve inter-operability with external tools (such as WML tools and WesCamp) and add some social content.
My personnal idea is adding some social content to addons. It means adding tags, which represents and defines in a more human way the addons.
Tags
Tags can be given by Wesnoth staff and by author. After discussing of it on IRC, users should not have the possibility of adding some tags to addons. By the way, authors can add tags too but NOT the same as those used by the staff.
There would be 2 types of tags: Registered ones, applied by the admins/staff, and "normal" ones applied by addon's author. Tags used by authors could be set freely or selected in a list defined by the server's admin.
Tags permit also to know which addons he liked, and search for addons he WOULD enjoy. It's a simple search function for tags, but it should be appreciated by users.
Tags would be added in the PBL file for each addon: (Documentation on PBL: PblWML) with the formating (in the _main.cfg, section campaign) :
authorTags="My First Tag","Cool Addon" officialTags="Best Addon Ever"
Tags could be also stored in a unique file for better search capacities. This file would be structured this way:
[tag] name="my cool tag" category="author" addonsId="orcish_incursion", "other_addon" [/tag]
Every time an addon is uploaded to the campaign server, its tags are selected, and if any match with the authorized tags are found, its id is added to the tag's file.
Server Side
Choices
I plan to work on the server code in C++, because:
- C++ can easily embed python directly, or with Boost C++ Libraries (which are already one of Wesnoth' dependancies)
- C++ runs on Linux AND stay easily portable to others platforms (Windows, Mac Os X...)
- The biggest part of Wesnoth is in C++, so why change ?
- Python tools like the WML suite of tools wan be easily usable directly from the server
Wescamp access via SVN
2 Solutions seem possible:
- Check the svn every time an user download an addon -> needs to implement the svn access directly from the server
- Check the svn on a regular basis -> Simple Cron Job
Documentation on svn apis in C, C++ and even python found there: http://svnbook.red-bean.com/en/1.1/ch08s02.html
Given this documentation, the simplest solution(except Cron job) to implement is to use Subversion's Python SWIG bindings (See Examples 8.2 and 8.3). The implementation of these exmaples is far more complicated in C or even C++. By the way, this solution needs one more dependancy.
Client Side
Wesnoth UI
The Client is too simple actually, so i'd improve it by adding some new lists:
- List of new addons
- List of most popular (After speaking of this idea on IRC, it's not a good idea after all. Elder addons are the most downloaded but not the best)
- Search box, looking after title, dates, authors, tags
Those lists would be accessible from a dashboard. This dashboard would welcome the user by showing him updates for addons he previously installed, and/or addons he would enjoy (based on tags).
Each addon should have an expanded view, and a simple view. The simple view is the view by default, clicking on a button "Show me more..." would expand the view.
Expanded view shows more informations:
- comment by the author
- tags (given by staff and by the author)
- list of actual translations (versionned): Ideally translations should be selected by default for the user language, but a menu showing addon's translation and their versions would be great.
- Date of creation
- Actually installed on user system ? (if so, an Uninstall button would be great)
Web UI
Each addon server could be accessible via a web interface (on port 80, or 8080).
Most general datas from Wesnoth Addon UI could be reachable from the Web Interface. It includes addons common datas (name, author, tags...) but also sort functionalities, like in the improved client UI.
The web server would be a simple TCP server listenning queries on a given port, integrated directly in the addon server. No use of apache (or even lighthttpd) is required for generating simple HTML pages.
Furthermore, an user account creation could be used to track users'data like "addons installed", "languages used...". After discussing of this with Mordante, it would be optional.
Admin UI
Both Wesnoth UI and Web UI should have an admin section, where server's admins can login and get special actions authorized:
- Add official tags.
- Set official tags for addons (add, remove, modify).
- Manage easily addons datas.
Admin Accounts would be stored in a special file:
[account] id="lao" password="ikhaiuhaz8U7687654V7YTF8655RFvvhg" #SHA1 encrypted password name="Lao" mail="lao.geek@gmail.com" [/account]
Timeline
Before Summer of code (until May 26)
- Work on small bugs/tasks for the Wesnoth Community
- Already done a patch for adding commandline options (patch #1031)
- Understand code used for the addon server/client, wml tools and wescamp.
- Being active in the developers community (IRC and forum), specially with mentor(s).
- Clearly design architecture of server-client
Part 1 - server side (1 month)
- Analysis of changes to be made (4 days)
- Refactor server code to integrate svn access to wescamp, and use of WML tools. (10 days)
- Add tags support and server-side functionnalities(1week)
- Implement Web interface (1 week)
Part 2 - client side (1 month)
- Gui design/mockups for both Wesnoth and web UI. (2 days)
- Implement Wesnoth normal client. (9 days)
- Implement Wesnoth admin client. (4 days)
- Implement Web normal client. (9 days)
- Implement Web admin client. (4 days)
After SoC
- Continue to work on bugs, tasks or Addon Server.
- Keeping on be active in the developpper community.
Motivation
I have chosen to participate for Wesnoth because it's one of the greatest Open Source game, given its gameplay, graphics, muliplayer games and last but not least: its community. I know there is a great community hanging out there, so being a part of it, is very pleasing for me.
So, why working on the addon server ? Because it's a very concrete network application (I would like to work as a pro in this area of IT) as client/server. There is a great base to update, polish and add new content. I think it can greatly improve the way people see the addons for Wesnoth, if users find more easily addons they'll like... Well they'll play more and more !
Actual Work for Wesnoth
I've submitted a patch for adding new commandline options, as requested on the forum and wiki. You can found my patch here.
The patch is now on the svn trunk (revision 25325).
Two new options are available with this patch:
-s, --server <host>
Direct connection to any server specified, or try to connect to the first server in user's preferences.
-c or --campaign
Skip Menu, and go directly to the "New Campaign" menu.
--with-replay
Replays the loaded game from --load option.