Just a comment; could Tinderbox's code be used to manage the
client/server interaction?
--Peter
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 c
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
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
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 convers
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
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 server
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 mi
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
> h
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
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, 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.)
>
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
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
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, Wind
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 si
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 conn
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
under
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 Ho
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 pa
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
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 ta
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 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 do
Le mercredi 11 février 2004 à 13:24, Michael G Schwern écrivait:
>
> 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
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
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 al
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 po
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
29 matches
Mail list logo
