gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: DynaGump (was Re: The Gump3 branch)
Date Sun, 09 Jan 2005 19:48:28 GMT
On 09-01-2005 17:40, "Adam R. B. Jack" <ajack@apache.org> wrote:
>> The goal now is to allow Gump3 to perform builds and put its data into
>> the database so that dynagump can start publishing it.
>> 
>> Everything else is secondary.
> 
> I agree, but I think Gump3 is a good idea and I'd like to see it for the
> long run.

I think we're all in violent agreement :-D

> The *right*/focused plan for now is to accept that Gump3 is months
> (and a lot of work) off

Yep! Oh man, so much work...

> (I know from experience) and that the shortest path
> to DynaGump is not Gump3. Work with me to finish the DynaGump actor for
> Gump2 that I wrote for you, and let's get it up and running. Let's start
> exercising/integrating DynaGump now, not wait for a core re-write.

The power I'm hoping to maximize on (and I think that was something Stefano
was getting at) is the power of the "clean sheet". Sam did this as well,
only the clean sheet he provided was so amazingly smart that we all had the
hardest time understanding it!

I'm guessing one of the key bits that makes a gump2/dynagump integration
difficult is just how much cool ideas Stefano has in his head wrt dynagump
and how immensely difficult it is to figure out how to weld those ideas into
gump2. Since gump3 has no outputs, no builders, no generators, we can start
with the kind of output we need and go from there. A "reversed" approach if
you will.

By starting with an "empty shell" like gump3, it becomes easier to visualize
how to do those things (its a hard hard problem to get right). From there,
we should be able to figure out together how to make gump2 deliver the
outputs that dynagump needs to fly.

It's not an or/or decision, its and/and. Let's just go with the flow. That's
always worked for the gump community so far. We're that good ;)

> The best thing that happened to Gump2 is that folks were running Gump1 in
> parrelel. Countless bugs were detected/resolved by being able to run side by
> side and compare. The best things we can do for Gump3 is allow Gump2 to talk
> to DynaGump in parrellel.

That makes a lot of sense.

> If we create a workspace on Brutus called DynaGump and configure it to a DB
> with both old and new DB schemas in it, we can have DynaGump up a running in
> no time.

Hehehe. Don't be too optimistic. The dynagump database schema as stefano
built seems to be completely different in some ways from how gump2 is set
up. Thinking about it hurts :-D

> Nothing (IMHO) better than running DynaGump against DBs formed by
> old and new Gump (2 & 3) and also comparing it to the HTML results generated
> by Gump2.
> 
> Let's allow Gump3 to be team formed by giving it time, whilst we make one
> incremental improvement and allow DynaGump to be born. Can we agree on this
> as a step in the plan?

Like I said, it makes sense. What I'd really love to see would be for you to
fully digest all the fledgling concepts in gump3 (after we figure out what
they are :-D) so you can figure out what kind of migration/integration/
reorganisation strategy makes sense.

And also, as I mentioned in my previous e-mail, I think we really don't need
a grand plan to all agree on. Baby steps. Python makes it so easy to glue
things up, there's a miriad of possibilities to make different versions of
gump all interoperate. We can figure all that out!

>> But I also hope that we'll work as a team this time.
> 
> Stefano, you make me smile. :-) You are so strong in your opinions (at least
> how they read to others) that you come perilously close to stymieing the
> community you love.

Hehehe. Take that, you passionate Italian! :-D

> Gump, however, is thriving
> community, and even when I was the only Python coder we had vast community
> efforts in metadata/management/communications
> (Wikis/Documentation/Blogs)/problem resolution/and so on. Gump's code is
> only a small component of it's whole.
> 
> I welcome more coders into Gump code, in fact I've longed for it & tried to
> encourage entry many times.Gump2 was a one man band 'cos nobody else wished
> to invest time and effort in a possibly dying venture, and yet out of it (in
> part by you helping it becoming a TLP) Gump was re-born and is once again
> thriving. Gump thrives based of it's contributions to the community, and
> hence their contributions to it (via metadata/effort) not due to the code. I
> welcome Gump3 as great opportunity for discussion and solving some mistakes
> of Gump2. Leo has address some, but not all (as I'll write) that need
> solving. I see no point in doing a re-write if after months and much effort
> we are no better off, and we've just shifted the one man team to a new man
> who we'll near burn out w/ all the 'implementation nits' that pure theory
> doesn't prepare you for. I'm no Leo, but I know this, I've been there.
> 
> Stefano, we are a team, and as a team we will have different world
> views/skill sets/insights -- and yes, have different weakness/make different
> mistakes. I'll keep raising concerns/issues based off my one-man-band wealth
> of experience, and hope we'll all keep an open mind to what is re-instating
> a past mistake, and what is a practical insight. Part of being a team is,
> perhaps, you educating me into your views/insights and me pressure testing
> them on me.

Amen. And likewise. The cool thing with open source is we all get to learn
from each other!

Cheers!

- LSD
 



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


Mime
View raw message