On 1/17/06, Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > Hi > > jerome lacoste wrote: > > I had some changes in mind compared to my original design proposal, to > > make it simpler. > > > > So I am willing to help you design & test this API/implementation and > > make sure it works with CruiseControl. > > Great! > > > I don't want to duplicate efforts so I would prefer a coordinator on > > that. Should I take back my original proposal and clean it up? Should > > we start from scratch? > > I'll be happy to coordinate the efforts here. Did you have time to look > at the quick draft I sent out last week in this thread? > > When it comes to designing the API I would be happy to start from > scratch if that makes it any easier for the users of the library. I > think we should strive for a simple API, in line with the XOM design > principles [1]. I especially would like us to follow "As simple as it > can be and no simpler", "There's exactly one way to do it" and "Do not > allow clients to do bad things". I don't think the current code fits > with any of these so there is some work to be done.
I agree with the principles. There's only one issue: backward compatibility. I have over 1000 lines of code that use the former API. So if the switch could be not too hard to do... > > Whatever the proposal, I want to see code examples to see how it would > > work in practise. > > Agreed, what would be the requirements for use within CC? More or less what was covered in my original API description document. My current need is to: - externalize the current Process execution to your library (reduce code in CC) - get more control on the spawned processes to be able to give the user a chance to kill them when something goes wrong. J --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
