Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Message-ID: <40635C6C.9050005@CodeRage.ORG>
Date: Thu, 25 Mar 2004 22:25:48 +0000
From: Michael Davey <Michael.Davey@coderage.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.6) Gecko/20040116
MIME-Version: 1.0
To: Gump code and data <general@gump.apache.org>
Subject: Re: [RT] Gump Architecture
References: <c3vjk3$sqg$1@sea.gmane.org> <4063567F.2000903@chalko.com>
In-Reply-To: <4063567F.2000903@chalko.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Nick Chalko wrote:

> I had thought of using a event / black board system to support a 
> distributed gump. Using something like javaspaces.

[snip workflow]

> This is a radically change but much more scalable.

Wow, what a [RT]!  I think this is a fantastic idea.  It might be worth 
taking a look at JXTA.  They have a python binding project, but I don't 
know what kind of state it is in.  You could always use JXTA-J as a 
temporary solution.

I guess the main advantage of JXTA would be that all those private Gumps 
would be helping out the build, unless they opt out (where as right now, 
private installations have to opt-in by asking to be listed on the Gump 
pages).

Regarding the workflow, I think the controller should also indicate the 
platform and java version to be used, so that individual peers could 
filter the build list and choose appropriate work units.  I guess that 
the controller would be responsible for nagging in this scenario.

I've got this vision of all these little gump tins around the world, 
each constantly fetching, building and submitting their work units, just 
like SETI-at-home!

-- 
Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org