(Created page with "=== An overview of your proposal === A daemon that listens to requests from system shell and responds with command line prompt dependant on context and user configuration. Mai...") |
No edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 5: | Line 5: | ||
=== The need you believe it fulfills === | === The need you believe it fulfills === | ||
It is possible to show repository status in command prompt without daemon, and there are solutions for almost every shell already. But if you try to use one of these solutions when working, for example, with kernel repository, you'll notice terrible delays. When entering kernel repo for first time, zsh could stop responding for more than minute. | It is possible to show repository status in command prompt without daemon, and there are solutions for almost every shell already. But if you try to use one of these solutions when working, for example, with kernel repository, you'll notice terrible delays. When entering kernel repo for first time, zsh could stop responding for more than minute. | ||
This problem can't be solved using simple shell script - long tasks, like checking repository status, should be done in background. Frequently used repositories could be checked even before they are entered at first time, but this requires separate daemon process too. Also, usually there are multiple terminal windows - multiple shells running. Sharing data between them could be a good idea. It could be easily implemented by using daemon too. | |||
=== Any relevant experience you have === | === Any relevant experience you have === | ||
*I have some experience of writing simple python scripts. Also I've contributed a bugfix to Guake, which is | *I have some experience of writing simple python scripts. Also I've contributed a bugfix to Guake, which is written in Python. | ||
*I got some experience of writing shell scripts when I worked on Laptop Mode Tools. | *I got some experience of writing shell scripts when I worked on Laptop Mode Tools. | ||
*I have a lot of experience with Git. Almost every project in which I participated was using Git as version control system. | *I have a lot of experience with Git. Almost every project in which I participated was using Git as version control system. | ||
Line 23: | Line 25: | ||
=== A rough timeline for your progress === | === A rough timeline for your progress === | ||
*21 | *April, 21 - May, 4: Start working on the project. Read documentation, think about architecture, experiment, etc. | ||
* | *May, 5 - May, 18: A daemon that responds with prompt generated only from query. Prompt will be already customizable at that time. | ||
* | *May, 19 - June, 1: Implement basic git support. No caching, no preloading, no optimizations. | ||
* | *June, 2 - June, 15: Experimenting with optimizations. | ||
*June, 16 - June, 22: Time for resolving any problems before midterm evaluations. | |||
*June, 30 - July, 13: Implement at least some optimizations. | |||
*July, 14 - July, 27: Implement support for Mercurial, Subversion, continue working on optimizations. | |||
*July, 28 - August, 10: Documenting, packaging. | |||
=== Any other details you feel we should consider === | === Any other details you feel we should consider === | ||
Line 33: | Line 39: | ||
=== Have you communicated with a potential mentor? If so, who? === | === Have you communicated with a potential mentor? If so, who? === | ||
Potential mentor - Mikolaj Izdebski | Potential mentor - Mikolaj Izdebski | ||
[[Category:Summer_coding_2014]] |
Latest revision as of 14:50, 21 March 2014
An overview of your proposal
A daemon that listens to requests from system shell and responds with command line prompt dependant on context and user configuration. Main target is showing current git repository status.
The need you believe it fulfills
It is possible to show repository status in command prompt without daemon, and there are solutions for almost every shell already. But if you try to use one of these solutions when working, for example, with kernel repository, you'll notice terrible delays. When entering kernel repo for first time, zsh could stop responding for more than minute.
This problem can't be solved using simple shell script - long tasks, like checking repository status, should be done in background. Frequently used repositories could be checked even before they are entered at first time, but this requires separate daemon process too. Also, usually there are multiple terminal windows - multiple shells running. Sharing data between them could be a good idea. It could be easily implemented by using daemon too.
Any relevant experience you have
- I have some experience of writing simple python scripts. Also I've contributed a bugfix to Guake, which is written in Python.
- I got some experience of writing shell scripts when I worked on Laptop Mode Tools.
- I have a lot of experience with Git. Almost every project in which I participated was using Git as version control system.
How do you intend to implement your proposal
I'll implement the daemon in Python, as usually every useful library have python bindings, so there won't be any problems with adding support for new version control system. Also, Python is present on almost every machine working under Linux.
- Support of different VCSes will be implemented through plugins.
- Maybe I'll also add support for Subversion and Mercurial.
- I'll implement some form of caching and/or preloading. Trial and error method here.
Final deliverable of the proposal at the end of the period
- Daemon written in Python.
- Possibly - client written in python too (if there will be problems in communicating with the daemon directly from shell).
- I can do packaging if it is needed.
A rough timeline for your progress
- April, 21 - May, 4: Start working on the project. Read documentation, think about architecture, experiment, etc.
- May, 5 - May, 18: A daemon that responds with prompt generated only from query. Prompt will be already customizable at that time.
- May, 19 - June, 1: Implement basic git support. No caching, no preloading, no optimizations.
- June, 2 - June, 15: Experimenting with optimizations.
- June, 16 - June, 22: Time for resolving any problems before midterm evaluations.
- June, 30 - July, 13: Implement at least some optimizations.
- July, 14 - July, 27: Implement support for Mercurial, Subversion, continue working on optimizations.
- July, 28 - August, 10: Documenting, packaging.
Any other details you feel we should consider
I study until end of May. Also, I have exams in June, but they won't take much time.
Have you communicated with a potential mentor? If so, who?
Potential mentor - Mikolaj Izdebski