[oops - I will get these subscriptions sorted soon! Resending only to the mailing-list]
> I think what would help the most right now would be a bit of guidance. > Can we take the C++ extension out of the tbzr installer as it is and > write > our own Python process for it? If not, what changes do we need to make > to the C++ code? Pretty much - the only changes I can think of are the name of the pipe and how to start the process. > As for the Python process, I think if you give us a bit more detail on > how > it communicates with the C++ shim, a number of developers are willing > to start working on it. Here's some specific questions: > > 1) How do the extensions discover the Python process? The name of a pipe is hard-coded in both the C++ and Python code, and a user-specific suffix if appended. If the pipe doesn't exist, we attempt to spawn the process and give up in disgust if we can't open the pipe in a couple of seconds - but even in that case, the next request should work quickly as the process is now running. > 2) How does it communicate (stdio, pipes, sockets)? named pipes using the windows API. > 3) How does it handle multiple connections? Just spawns a new thread while the connection remains alive. Its not ideal but the number of open connections should be fairly low, and certainly they all won't be communicating at once. On the plus side though, this can change without the c++ knowing (the c++ treats the connection to the server as a singleton and uses locks where necessary, which shouldn't be a problem in practice I don't think) The binary protocol used is pretty horrid but effective. Both sides are expected to agree on exactly what is being passed (eg, a request for menu items for a file name may return an integer, and a list of (string, string, int)s) - all integers are passed as 64 bits, strings write a length then the data, and arrays of anything simply write the number of items followed by the items themselves. All strings are ucs2 (or is it utf16?) - ie, a 'wchar_t' for windows. The data is preceeded by the 'version number' of the request (so we know client and server are in synch) and the total number of bytes in this request (for basic sanity checking while unpacking the data.) If the client and server aren't in synch we just refuse to process the request - this is only likely after an upgrade but before a reboot. Something else I meant to mention is that there is a Python impl of the shell extension in the parent of the c++ source code; the c++ code is a fairly faithful port of that Python code, apart from the data unpacking (the python code cheats and uses the struct module) Mark ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
