gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <>
Subject Random Gump3 questions
Date Wed, 06 Apr 2005 15:25:48 GMT
Here are some random thoughts/questions, on things I'd like to see explored
with Gump3. I'd appreciate insights on if they are good requirements (for
now) and/or how we might design them in:

1) External PlugIns

I'd really like to hear design/implementation ideas about
discovery/life-cycle of plug-ins to Gump3. I'd like us to get this sorted
early to stop us thinking "closed" & allow more contribution. If we can
implement something (or, better, leverage Python somehow) I'd implement a
standalone RDF-generating plug-in, for the exercise of it all.

I think we need to be able to register (e.g. via the workspace, or via
placing in a certain directory, or whatever) Python code as a plug-in, just
as simply as we have our own plug-ins. If the code could be discovered,
loaded, and managed I think we'd be in a good position to allow folks to
(say) plug-in their own Perforce updater, or builder, or whatever etc.

I know this might "stretch" us on getting interfaces (internal APIs) right,
but I think Gump3 is about trying to get it "right", and this seems a big
one to me.

2) OnDemand Metadata Loading

One of the problems with Gump today is it's need to load all the metadata in
the workspace, to build a huge internal tree, in order to then (say) build
just a few things. I think it'd make sense to have a more "on demand"
approach, downloading as needed, to make Gump more "interactive friendly".
The main use case might be testing (i.e. does Gump w/ this code hack still
build ant, or does this project/descriptor change still build under Gump)
but I think these are good use cases.

3) Federation

Along with (2) I think we need to think more about federation and/or
delegation. The initial use case might be a site depending upon Apache work,
but not wanting to duplicate Brutus. As such, I think we need the concept of
"loading metadata for reference-only verse for processing". Not sure it buys
us a lot, but I think this is along the lines of (2) above. Meaning, we can
know that there is a project named Ant, but we might not need to know
details of it's SCM repository if we aren't going to try to build it.

4) Repository management.

I do think we need to have "build from repository" (use last night's
successful build if today's fails) in Gump3. Any thoughts on where/how this
might fit?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message