<div>Software Development Methodology!!!!</div><div><br></div>1. Use Cases<div>2. Requirements</div><div>3. Proposed Technical Design</div><div><br></div><div>Bonus points if you include Visio diagrams!!!!</div><div><br></div>
<div>Top-posted for genuine experience!!!!</div><div><br><div class="gmail_quote">On Mon, Oct 10, 2011 at 9:53 AM, Glyph <span dir="ltr"><<a href="mailto:glyph@twistedmatrix.com">glyph@twistedmatrix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>Hi Andrew,</div><div><br></div><div>Thanks for your work on this.</div><br><div>
<div class="im"><div>On Oct 7, 2011, at 1:45 AM, Andrew Mahone wrote:</div><br><blockquote type="cite"><div>I've been working on <a href="http://twistedmatrix.com/trac/ticket/4159" target="_blank">http://twistedmatrix.com/trac/ticket/4159</a> and<br>
there has been a bit of discussion on IRC regarding appropriate<br>interfaces for various things. I think in the long run, the only<br>python state that setupChild should be allowed to modify should be<br>args, environment, and the win32 StartupInfo object. This leaves my<br>
own personal use case for it impossible, but I'm working out how to<br>handle that - special childFDs objects. My proposal so far is that<br>there be a ProcessFileDescriptor object that inherits from<br>FileDescriptor. It would add a setup method, which Process would call<br>
in the parent, and separate finishChild and finishParent methods that<br>would handle things like closing the other end of any pipe-like<br>objects, and would return a file descriptor - the child would place<br>this fd in childFDs, the parent would use it for communications with<br>
the child, in the case of objects that wrap pipes or PTYs. I would<br>also extend the win32 implementation to include some limited support<br>for childFDs - they could be used to allow the child to inherit<br>specific file handles as its stdin, stdout, and stderr, instead of<br>
using these exclusively for communications with the parent, so that<br>redirection to a pipe, to a file, and the building of pipelines could<br>be accomplished on win32 (I have a project that uses twisted for this<br>purpose, and I don't use windows, but I would like support to at least<br>
be possible).<br></div></blockquote><div><br></div></div><div>I've been sitting on this message for a couple of days trying to come up with a good reply. Unfortunately this whole description is phrased in terms of conflicting desires for the implementation, rather than a design strategy or a set of goals or requirements for the API, so my attempted replies have ended up playing whack-a-mole with the concerns one at a time, rather than making an informed critique of the whole proposal.</div>
<div><br></div><div>Could you try to re-phrase your design here in terms of why we want each of these things, some use-cases, and then maybe spell out the methods and stuff in terms of Python interfaces or classes (or perhaps links to your patch if it already implements what you've described here)?</div>
<div><br></div><div>Sorry that this probably isn't terribly useful feedback. I really appreciate the time you've put in thus far, and I <i>think</i> I like where you're going with this, I just haven't had time to turn everything inside-out so that I can see it clearly :).</div>
<div class="im"><div><br></div><blockquote type="cite"><div>I'm seeking comments on whether an extended childFDs interface is the<br>best way to manipulate the inherited files of the child process, and<br>whether, if so, fdmap ought to be visible in setupChild at all - in my<br>
opinion, setupChild should be strictly for things like setting the<br>child PID in an environment variable or as a command line argument,<br>manipulating scheduler and other parameters external to twisted<br>itself, and other things of that nature, and the existing childFDs<br>
mechanism should handle any manipulation of file redirection or<br>inheritance. If there are suggestions on what an extended childFD<br>object ought to look like, these are welcome as well - I think the<br>specified methods should handle trivial cases even on platforms<br>
without fork, and should handle nearly anything that really is a file<br>descriptor on POSIX platforms, but maybe there is something I have<br>missed.</div></blockquote><br></div></div><br></div><br>_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Christopher Armstrong<br><a href="http://radix.twistedmatrix.com/">http://radix.twistedmatrix.com/</a><br><a href="http://planet-if.com/">http://planet-if.com/</a><br>
<br><br>
</div>