## page was renamed from SummerOfCode2009/StudentApplicationTemplate
#language en
* [[http://selenic.com/repo/hg/search/?rev=Idan%20Kamara&revcount=40|Submitted patches]]
* [[http://idankgsochg.blogspot.com/|Blog]]
= Command Server Project Proposal =
* '''Name''': [[IdanKamara|Idan Kamara]]
* '''Contact''': idankk86@gmail.com, idank on #mercurial
* '''Background''': I'm a Computer Science and Mathematics undergraduate in the Open University of Israel.
My first meeting with Mercurial was in my previous work place. At the time I started working there, the development teams were using a (god forsaken) source control called StarTeam. I quickly grew tired of it and started looking for alternatives to take its place. Among the top DVCSs at the time, my absolute favorite was Mercurial due to its user-friendly approach, low learning curve, cross platform and a very open and helpful community. <
>Since then I've been following Mercurial looking for opportunities to give back. GSoC looks like a great one.
Most of my programming experience is in C++, Iv'e also done some Java and C# here and there. I've been using Python for a lot of small tasks the past couple of years but I've always wanted to see how a real application is written using it and in my opinion Mercurial is an excellent example of one.<
>
* '''Project title''' Command Server
* '''Synopsis''': Mercurial's primary stable API is its command line interface. Creating a tool and library to communicate with this API over a pipe or a socket will help improve performance for third-party tools that use Mercurial.
* '''Benefits to Mercurial'''
* As stated above, improving performance (saving process startup time, cache the repository object).
* It can also benefit regular users by having a small, fast client talk to the server directly.
* Easier integration with Mercurial for programming languages other than Python.
* Allow a remote repository to be queried without needing a local clone.
* '''Deliverables''':
* A functioning server.
* A sample client (possibly a tiny C program that simply forwards its argv to the server, can be used instead of hg's main python module by regular users).
* Make the test suite pass while using the server rather than talking to hg directly.
* '''Project details''':
When integrating with Mercurial, the recommended approach by the Mercurial team is to use the command-line interface.
Mercurial goes to great lenghts to make sure the command-line interface doesn't change very often, thus ensuring existing tools who rely on it stability when upgrading.
The other, unrecommended option (available to Python applications) is to use Mercurial's internal API [1], yielding better performance and more control at the cost of possibly breaking between releases of Mercurial (an example of such tools can be seen here [2], [5]).
The command server will aim to be the best of those two worlds. It will maintain stability throughout Mercurial releases and offer better performance over calling the command-line interface directly.
Existing tools I've looked at (MercurialEclipse, TortoiseHg, VisualHG, MacHG etc.) take the recommended approach and use the command-line interface. This is done by opening a process for every hg command.
Tools written in Python usually import Mercurial and call it directly (saving process creation).
The specifics of how the requests to the server is to be determined, but an initial thought is something of this sort: ";". The servers answer might look like this: ";