On Sun, Mar 14, 2004 at 10:31:44PM -0600, Scott Bolte wrote:
Just for the record, I've abandoned the HTTP::Daemon changes
that supported using two unidirectional pipes. Given what
I've learned, I believe the HTTP protocol precludes that
mode.
The problem is
On Mon, 15 Mar 2004 10:30:30 +, Tim Bunce wrote:
...
The problem is reading some types of response messages.
When using sockets, the server closes the socket after a
sending a response without a Content-Length field. The
resulting EOF allows the client to
Just for the record, I've abandoned the HTTP::Daemon changes
that supported using two unidirectional pipes. Given what
I've learned, I believe the HTTP protocol precludes that
mode.
The problem is reading some types of response messages.
When using
Le lundi 23 février 2004 à 14:06, Michael G Schwern écrivait:
I'm going with just straight, unsecured socket communications and an ad hoc
protocol. At this point, encryption is not necessary. There's nothing worth
encrypting. To see why, look at the example protocol conversation at
On Mon, Mar 01, 2004 at 05:37:39PM +0100, Philippe 'BooK' Bruhat wrote:
I'm going with just straight, unsecured socket communications and an ad hoc
protocol. At this point, encryption is not necessary. There's nothing worth
encrypting. To see why, look at the example protocol conversation
Michael G Schwern sent the following bits through the ether:
So what I need is some way to set up a network of test servers such that
I can say test this module for me and my testing client would ship it
to as many test servers as it can find and get the results back all in
just a few
Le lundi 01 mars 2004 à 16:53, Leon Brocard écrivait:
Michael G Schwern sent the following bits through the ether:
So what I need is some way to set up a network of test servers such that
I can say test this module for me and my testing client would ship it
to as many test servers as it
On Mar 1, 2004, at 9:12 AM, Philippe 'BooK' Bruhat wrote:
Which means the server and client could communicate as IRC bots,
with Net::IRC or a similar module?
Jabber.
David
On Sun, Feb 22, 2004 at 12:35:03PM +, Nick Ing-Simmons wrote:
See above. Yes, ssh is not portable enough.
Well runs on Linux/Unix and Win32 has at least a client
so which platforms is VMS the problem?
VMS and Windows. While it exists for Windows, it typically isn't a simple
command
On Sun, Feb 22, 2004 at 06:36:22AM -0600, Scott Bolte wrote:
On Sun, 22 Feb 2004 01:07:38 -0500, Michael G Schwern wrote:
See above. Yes, ssh is not portable enough.
Where is the gap? I have OpenSSH on every Unix platform I
use and, with cygwin's help, all the windows based
Michael G Schwern [EMAIL PROTECTED] writes:
On Thu, Feb 19, 2004 at 08:35:28AM +, Nick Ing-Simmons wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
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,
On Sun, 22 Feb 2004 01:07:38 -0500, Michael G Schwern wrote:
See above. Yes, ssh is not portable enough.
Where is the gap? I have OpenSSH on every Unix platform I
use and, with cygwin's help, all the windows based systems
too. I can even log *into* a w98 host with ssh.
On Sun, Feb 22, 2004 at 06:36:22AM -0600, Scott Bolte wrote:
On Sun, 22 Feb 2004 01:07:38 -0500, Michael G Schwern wrote:
See above. Yes, ssh is not portable enough.
Where is the gap? I have OpenSSH on every Unix platform I
use and, with cygwin's help, all the windows based
On Sun, 22 Feb 2004 16:13:01 +, Tim Bunce wrote:
Now I do agree the HTTP protocol is worth using for managing
the flow of data. I run HTTP over ssh myself. (I modified
HTTP::Daemon to use two unidirectional pipes instead of a
single, bidirectional socket.)
Has
On Wed, Feb 18, 2004 at 06:49:19PM -0600, Ken Williams wrote:
1) In order to be convenient for the code author, he/she should be able
to poll for available clients before submitting a job. My inclination
would be to make this a simple inetd on the client, rather than any
persistent
On Thu, Feb 19, 2004 at 08:35:28AM +, Nick Ing-Simmons wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
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
On Thu, 19 Feb 2004 08:35:28 +, Nick Ing-Simmons wrote:
How about layering it on ssh then?
That has done all authentication stuff already.
I agree. With empty passphrases and/or ssh-agent it is very
easy to set up automated commands. Add forced commands (an
Michael G Schwern [EMAIL PROTECTED] writes:
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 +, Adrian Howard
On Wednesday, February 11, 2004, at 09:24 pm, Michael G Schwern wrote:
The biggest time suck in developing MakeMaker, and to a lesser extent
Test::More, is running the tests. Why? Because they need to be run on
lots of different platforms with lots of different versions of Perl.
Currently, I
On 2/12/2004 9:07 PM, Randy W. Sims wrote:
How about a model that allows people to volunteer when they can (vs
always). Say you have a server. You would be an author-client. You'd say
I have this software that needs to be tested. The server would take it
and mark it available for testing.
On 2/16/2004 5:25 PM, Michael G Schwern wrote:
On 2/12/2004 9:07 PM, Randy W. Sims wrote:
How about a model that allows people to volunteer when they can (vs
always). Say you have a server. You would be an author-client. You'd say
I have this software that needs to be tested. The server would
Some thoughts:
1) In order to be convenient for the code author, he/she should be able
to poll for available clients before submitting a job. My inclination
would be to make this a simple inetd on the client, rather than any
persistent connection between client server. I think if there were
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 +, Adrian Howard wrote:
- If this is going to be run by
Le mercredi 11 février 2004 à 13:24, Michael G Schwern écrivait:
Here's a simple sketch of what I'd imagine the protocol would look like.
I'm not much on networking, so I'm going to keep it simple. HTTP is
simple. I'd also like to make running a test server as simple and
portable as
On 2/11/2004 4:24 PM, Michael G Schwern wrote:
The biggest time suck in developing MakeMaker, and to a lesser extent
Test::More, is running the tests. Why? Because they need to be run on
lots of different platforms with lots of different versions of Perl.
Currently, I do this by hand. And we
On 2/12/2004 9:07 PM, Randy W. Sims wrote:
How about a model that allows people to volunteer when they can (vs
always). Say you have a server. You would be an author-client. You'd say
I have this software that needs to be tested. The server would take it
and mark it available for testing. Then
The biggest time suck in developing MakeMaker, and to a lesser extent
Test::More, is running the tests. Why? Because they need to be run on
lots of different platforms with lots of different versions of Perl.
Currently, I do this by hand. And we all know manual testing sucks.
Its time consuming
27 matches
Mail list logo
