Mailing-List: contact gump-help@jakarta.apache.org; run by ezmlm
To: gump@jakarta.apache.org
From: Sam Ruby <rubys@apache.org>
Subject: Re: [RT] gump.py
Date: Sun, 13 Apr 2003 11:34:09 -0400
Lines: 63
Message-ID: <b7c00i$pit$1@main.gmane.org>
References: <b7brbv$cq4$1@main.gmane.org> <b7bu6e$kik$1@main.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
In-Reply-To: <b7bu6e$kik$1@main.gmane.org>
Sender: news <news@main.gmane.org>

Stefano Mazzocchi wrote:
>>Next is the actual Gump Object Model.  The way the base classes are 
>>defined, only the non-leaf parts of the gump object model which actually 
>>have logic associated with them require definition.  The definitions 
>>consist of simple declarations of expected elements, and whether one or 
>>multiple elements are expected of each.
> 
> In light of a future chance of using gump for non-java projects,
> wouldn't it be better to name this object model with names which are
> semantically connected to the functionality they wrap and not with the
> tool that currently implements it?

Change it.

I made a number of changes to the current Gump based on peoples input. 
I moved from 100% xslt to recoding the major portion of the front end in 
Java based on complaints that Gump would never have a development 
community unless it were rewritten in Java.  I have not seen a 
significant difference in participation in the two parts of Gump.

This RT is not an experiment to see if I can code more efficiently in 
Python than Java, but to test the assertion that if Gump were recoded in 
Python that it would attract a larger community.

>>Next, we need to figure out how to handle external project definitions. 
>>The speed of this script would degrade significantly if these were 
>>read every time.  Either some sort of caching which is only explicitly 
>>updated based upon request is needed, or a serialization of the full 
>>merged definition (like to the current Jenny logic does) is required.
> 
> I don't understand this, can you be more specific?

Try running the provided script.  It takes one to two seconds on the 
three machines I have tried it on.  It occurs to me that I could use 
this infrastructure to do builds directly from the gump definitions 
WITHOUT any need for a generation step.

Add in all the HTTP gets, and this is likely to take a minute or more, 
even with a fast internet connection.

>>Finally, the logic current placed in XSLT stylesheets would need to be 
>>accomondated.
> 
> Do you still envision the use of XSLT?

I have no preconceived notion at this time.  I will say that I am a big 
fan of Cheetah, which is a Python port of Velocity.

http://www.cheetahtemplate.org/

My weblog is powered by Cheetah.

>>Given the way that this implementation unifies elements and attributes, 
>>it is regretful that projects have a package attribute (which indicates 
>>where the installed packages reside) and a package element (which 
>>identifies the java package(s) a given project implements).
> 
> I don't get it: both attributes and elements become object properties?

Yes.  I hope my examples in the provided source illustrate this well.

- Sam Ruby