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/12 11:15] sunweaver |
events:gsoc2013 [2013/03/28 21:02] sunweaver [Schedule] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Google Summer | + | ====== Google Summer |
===== Contact Information for Applying Students ===== | ===== Contact Information for Applying Students ===== | ||
Line 16: | Line 16: | ||
===== Schedule ===== | ===== 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 8 19:00 UTC Google announces the list of accepted mentoring organizations | + | * 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 ===== | ===== Application of X2Go Project for GSOC2013 ===== | ||
Line 30: | Line 38: | ||
However, if you do not sense affinity to any of the project ideas listed below, feel free to propose your own code project idea. | 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 / X2Goplugin | + | ==== 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:// | ||
Line 44: | 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 60: | Line 68: | ||
* Add a session profile storage (on a per-user basis) based on e.g. 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. |
==== JSON based protocol for communication between X2Go Client and X2Go Session Broker ==== | ==== JSON based protocol for communication between X2Go Client and X2Go Session Broker ==== | ||
Line 66: | Line 74: | ||
* JSON is a very appropriate data format when two applications what to exchange data objects via text base communication streams | * 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 | * 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< | + | * 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 | * 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 | ||
- | ==== Interface between LightDM' | ||
- | |||
- | * 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:// | ||