events:gsoc2013
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
events:gsoc2013 [2013/03/10 09:51] sunweaver [X2Go related Tasks that could be submitted to GSOC 2013] |
events:gsoc2013 [2013/03/28 21:02] sunweaver [Schedule] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Google Summer | + | ====== Google Summer |
| + | |||
| + | ===== Contact Information for Applying Students ===== | ||
| + | |||
| + | * Mail(inglist): | ||
| + | * IRC: Channel #x2go on '' | ||
| + | * Contact persons: Heinz-Markus Graesing (IRC: '' | ||
| ===== Information about this year's event ===== | ===== Information about this year's event ===== | ||
| * [[http:// | * [[http:// | ||
| Line 5: | Line 12: | ||
| * [[http:// | * [[http:// | ||
| * [[https:// | * [[https:// | ||
| - | * [[http:// | + | * [[http:// |
| * [[http:// | * [[http:// | ||
| - | ===== Deadlines | + | ===== Schedule |
| - | * March 18 19:00 UTC Mentoring organizations can begin submitting applications to Google | + | * March 18 19:00 UTC -- Mentoring organizations can begin submitting applications to Google |
| - | * March 29 19:00 UTC Mentoring organization application deadline | + | * March 29 19:00 UTC -- Mentoring organization application deadline |
| + | * April 08 19:00 UTC -- Google announces the list of accepted mentoring organizations | ||
| + | * April 22 19:00 UTC -- Students can start handing in their code project proposals | ||
| + | * May 3 19:00 UTC -- Student code projects proposal deadline | ||
| + | * May 06 -- Mentoring organizations should have requested slots in Google Summer of Code 2013 site at this point | ||
| + | * May 08 -- Slot allocations published to mentoring organizations | ||
| + | * May 22 -- First round of de-duplication checks happens; organizations work together to try to resolve as many duplicates as possible | ||
| + | * May 24 -- Student acceptance choice deadline, initial IRC meeting, sorting out duplicate acceptances of students, mentors must be assigned to students | ||
| + | * May 27 19:00 UTC --Accepted student proposals announced on the Google Summer of Code 2013 site | ||
| + | |||
| + | Futher timeline information can be found [[http:// | ||
| + | ===== Application of X2Go Project for GSOC2013 ===== | ||
| + | |||
| + | Our application draft can be viewed/ | ||
| ===== X2Go related code projects that could be submitted to GSOC 2013 ===== | ===== X2Go related code projects that could be submitted to GSOC 2013 ===== | ||
| - | ==== X2Go Client / X2Goplugin | + | |
| + | Below you find a list of code projects that we (X2Go upstream) are interested in. Most of the projects we have on our todo lists, anyway, but there are always other things that sneak in as more important. Getting help by some genuine people on the code projects listed below would be really awesome. | ||
| + | |||
| + | However, if you do not sense affinity to any of the project ideas listed below, feel free to propose your own code project idea. | ||
| + | |||
| + | ==== X2Go Client / X2Go Plugin | ||
| * As [[http:// | * As [[http:// | ||
| * As it is only possible to install applications on chromeOS (running on an original chromebook) via the [[https:// | * As it is only possible to install applications on chromeOS (running on an original chromebook) via the [[https:// | ||
| - | ==== Access | + | ==== Access |
| * It's difficult for the X2Go Project to offer clients on a number of mobile devices lacking an X.Org server and with rules that make it very difficult to submit GPL'ed software to their ecosystems. | * It's difficult for the X2Go Project to offer clients on a number of mobile devices lacking an X.Org server and with rules that make it very difficult to submit GPL'ed software to their ecosystems. | ||
| * An HTML5 Client could help to build native apps and render sessions on a [[https:// | * An HTML5 Client could help to build native apps and render sessions on a [[https:// | ||
| Line 27: | Line 52: | ||
| * The weakness of X2Go definitely is the NX Xserver used for display server session on the client | * The weakness of X2Go definitely is the NX Xserver used for display server session on the client | ||
| * This coding project would be a start to gradually update the Xserver extensions shipped with NX | * This coding project would be a start to gradually update the Xserver extensions shipped with NX | ||
| - | * During this project you will get a deep insight into Xserver code. You need good C and Cplusplus skills to start this code project. | + | * During this project you will get a deep insight into Xserver code. You need good C and Cplusplus skills to start this code project. |
| ==== X2Go Desktop Applet ==== | ==== X2Go Desktop Applet ==== | ||
| Line 39: | Line 64: | ||
| ==== X2Go Session Broker WebGUI Service ==== | ==== X2Go Session Broker WebGUI Service ==== | ||
| - | * Similar to Canonical' | + | * Similar to Canonical' |
| * This will need an extension of the X2Go Session Broker: | * This will need an extension of the X2Go Session Broker: | ||
| - | * Add a session profile storage (on a per-user basis) based on MongoDB | + | * Add a session profile storage (on a per-user basis) based on e.g. MongoDB |
| * Make these session profiles configurable through a nice WebGUI | * Make these session profiles configurable through a nice WebGUI | ||
| - | * The current public implementation of the X2Go Session Broker is written in Python. | + | * The current public implementation of the X2Go Session Broker is written in Python. The difficulty is medium. Interests in Web2.0 development strategies is of advantage. |
| - | ==== Interface | + | ==== JSON based protocol for communication |
| + | |||
| + | * JSON is a very appropriate data format when two applications what to exchange data objects via text base communication streams | ||
| + | * Currently, X2Go Client and X2Go Session Broker currently communicate over a plain text base communication protocol. This protocol is not very tolerant about errors | ||
| + | * To make the client< | ||
| + | * However, transparent backward compatibility must be granted at the same time: new X2Go Clients must continue to be able to speak the older broker protocol, new X2Go Session Brokers must be able to understand old X2Go Clients | ||
| + | * Good knowledge of Qt4 and Cplusplus are required for this task | ||
| - | * The remote login feature in LightDM uses UCCS for session brokerage. The UCCS is a very public service. The main caveat is: UCCS offers to store user passwords and these passwords (at time of Ubuntu 12.10 and Ubuntu 13.04) get stored in plaintext at Canonical (or at least can be easily unhashed). A site admin surely would love to have such a web portal as UCCS at hand, so that the remote login feature can be used on the local network without Canonical as the brokerage provide in the loop. | ||
| - | * This code project is to provide a drop-in replacement for the Ubuntu package '' | ||
| - | * The users shall then be able to use LightDM' | ||
| - | * Versatile skill are needed for this: C, Cplusplus, XML, JSON, Python. | ||
| + | ==== PyHoca-PubAppDaemon - transparent X2Go Published Applications Integration into local Desktops ==== | ||
| + | |||
| + | * This idea focuses on X2Go integration into Unity desktops (for providing hybrid fat/thin clients) | ||
| + | * All multimedia intensive applications are run locally (using server-side dot files in a server-side home directory) | ||
| + | * Anything else runs on an X2Go terminal server | ||
| + | * The desktop shell' | ||
| + | * X2Go offers a feature called X2Go Published Applications | ||
| + | * The feature allows starting of X2Go sessions of the type PUBLISHED on remote application servers. This session merely returns an application menu tree (and a slumbering x2goagent). Currently this menu tree is rendered by X2Go Client / PyHoca-GUI as a submenu of their systray icon. From this menu tree you then can select individual applications to get launched within your local desktop shell | ||
| + | * However, how would it be if one could smoothly merge the remote menu tree into the local desktops application menu? | ||
| + | * Or even more, drag' | ||
| + | * Or even better, dock those applications to Unity' | ||
| + | * An approach to realize this would be a split up of PyHoca-GUI: PyHoca-PubAppTrigger and PyHoca-PubAppDaemon. | ||
| + | * On remote login (LightDM) a guest (Ubuntu) session gets launched and in the background PyHoca-PubAppDaemon waits for commands via a Unix domain socket file | ||
| + | * PyHoca-PubAppDaemon can be queried for server-side provided applications (a list of .desktop files plus base64 encoded icons) | ||
| + | * The returned menu items are merged into the local application menu | ||
| + | * A click on one of those (local) .desktop files (executing a published application) will launch PyHoca-PubAppTrigger. This trigger talks to the PyHoca-PubAppDaemon and initiates the launch of the requested server-side application (via the X2Go Published Applications feature) | ||
| + | |||
| + | The task is rather complex and demands quite a bit of understanding of the FreeDesktop.org specifications. The whole project will be in Python. A draft for the login process is already available on [[http:// | ||
Imprint & Legal Disclaimer -
Data Protection & Privacy Statement
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3