Re: [Queue-developers] new design details

[Koni <mh...@co...>]

On Wed, 2005-05-11 at 22:01 -0700, wernerkrebs wrote:
> Progamming is partially an artform as much as a
> science, and it's usually best to try to use the most
> modern techniques that everyone else is using. This
> way, you can leverage off what other people in the
> community are doing, and develop synergy with other
> projects. GQ was modern for its time, but lots has
> happened since it came out.
> 

I agree here in principle, but some things that might be called modern
techniques are really just trendy to me. 

I think we (we as in all interested parties on this list) first need to
sort out a couple critical items:

First, do we wish or intend to subscribe firmly to the RMS point of view
of free software for this project? If GNU Queue remains "GNU", then I
think this is most relevant albeit restrictive. A firm commitment to
that would limit our discussions about mysql or high performance
commercial database backends and use of Java or C#/Mono. 

Second, I think we should define a limited scope of problems that GQ
will purport to solve and do that well. I am confused by the idea of
meta-clustering. It seems like it won't be much work on us to have some
meta-controller interface with GQ's controller, but why do people do
this? I can think of a few reasons, but are the needs of these
applications fitting within the problem space we want to address?

I see a growing market of small dedicated homogeneous systems with
simple distribution needs, driven by cheap computer prices. In time up
to present or perhaps into the future some more, interest heterogeneous
and non-dedicated systems I think is coming from interest in tapping the
resource of idle desktop CPUs. With that comes substantial complexity
that other projects like condor have embraced and seem to be doing
well. 

I don't think its beneficial to GQ to try to tackle some of the same
problems if condor already fills that niche. I also think many groups
with new interest in this area will have small dedicated systems and be
looking for something simple and easy. Thus, this seems like an
expanding niche that would be well filled by something that takes 2
minutes to setup and start using. GQ can do this, especially if it is
stand-alone with no backend database and no library dependencies.  

I think the ease of setup and use will make a big difference in the
adoption of GQ as a solution in the situations where it is applicable.