gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Distributed Gumps
Date Tue, 18 Nov 2003 22:01:02 GMT
As I (bit by bit) put Python Gump back together & work out the little issues
generated by the re-work, I want to start thinking about next steps. Having
xdoc output & pretty forrest sites (btw: thanks for the blue background logo
Nicola) isn't meant to be the goal, just a feature. Since Gumpy is more OO,
I wish to leverage that to do something seriously useful, above and beyond
what could've been done before.

That all said, Gump is an information communicator, so requests for
improvements on the presentation (see http://lsd.student.utwente.nl/gump/)
are welcomed. [Note: I've added repository lists, XML definitions on the key
objects, and started on cross reference information. Also, the RSS feed
ought be less verbose now also, using the statistics database to only
publish the first time a state changes.]

BTW: gump.dotnot.org is down right now, Python Gump wasn't playing nicely w/
the OS. Strangely this doesn't happen on LSD (Py 2.2.1), or Chalko (Py
2.2.2), or others, so I'm hoping it is the instance of the Python install on
dotnot (2.2.3) & that an upgrade will help out. Maybe a stab with Python
2.3.

BTW: Other side tasks -- (1) update cvs.apache.org to stop pointing to old
data (2) work to get gump.apache.org on moof [assuming no Linux box gets
offered up] (3) update documentation (4) start nagging [I'll ask here
first].

So, I'm thinking next steps, and "distributed gumps" is still the hot
favourite. This could been seen a few ways, but I interpret it as cascading
gumps to save on cycles. In effect, one Gump would "reach up and borrow" a
latest set of outputs (jars) from another. This brings in some interesting
issues, like timing and what if the "latest" from another Gump isn't 100%
the latest (due to a build failure or ongoing compile), and so forth. It
also brings up the idea of "collections of Gump metadata" (distributing that
in chunks.)

Even though it introduces interesting issues, I feel that this is a way
(perhaps better than a GUI) to get Gump out to more places, to get more
projects Gumping. The goal being better Gump coverage of OSS, the goal being
more successful collaborations & deeper [yet stable] OSS stacks.

Not that this is a new topic, but what are folks thoughts on this?
Worthwhile? Nuts? Any implementation pointers/thoughts?

Thanks in advance.

regards,

Adam
--
Experience Sybase Technology...
http://www.try.sybase.com


Mime
View raw message