One thing to keep in mind is portability. In order for this to be useful it has to run on pretty much all platforms. Unix, Windows, VMS, etc... So I'm trying to keep it as simple as possible.
On Wed, Feb 18, 2004 at 05:29:49PM +0000, Adrian Howard wrote: > - If this is going to be run by paranoid people everything would have > to be over https to prevent man-in-the-middle attacks on the code being > transported HTTPS might be overkill, we don't need to encrypt the communications, just identify the server. A simple thing to do would be for my server to have a public/private key pair. The clients ship with or they download my public key. Then later when they communicate they encrypt a little string with my public key, I decrypt it and send it back for verification. Simple. Not something I'm going to worry about in the beginning, but definately later. > - I've done a vaguely related task in the past. Instead of > distributing one test suite over several machines, I was distributing bits > of a single test suite over several machines (so I could run the test > scripts in parallel and decrease the overall runtime of the whole test > suite). Would be nice if we had something flexible enough to cope with > both scenarios - but that might make it too complex to implement in a > day or so :-) Can I get a pony with that? Thanks. ;) > - I solved my problem with SSH rather than HTTP since I had the > infrastructure for it in place on the machines I was playing with. > Might be worth considering as an alternative to HTTP[S] Perl has native HTTP libraries. Perl doesn't have native ssh libraries. >From a portability standpoint, the choice is clear. ssh also requires that the clients have accounts on the server machine. Extra complexity and security issues. In reality I'll probably forgo either of them and just write a very simple network daemon to speak a simple text protocol. Very little information needs to be passed back and forth. > - Would you want to deal with cannot test (e.g. because the test > server didn't have the necessary prerequisite modules rather than the test > itself timing out or there being a communication problem) as well as > pass/fail? Part of the client's logic is to be able to download and install the prereqs, probably just assume there's a working CPAN.pm installation. They'd be installed in a seperate directory so as not to mess with the system Perl libraries. > - Some mechanism to automatically gather/report the base platforms > would seem to be a good idea. Otherwise you are going to have people > forgetting to keep the central list up to date when then update their > box. This I don't understand. There's nothing for the user to keep up to date by hand. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ HA HA HA You're all so rediculous! But thanks for the money!
