> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
> Sent: 27 March 2002 10:09
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Cactus Gump project descriptor in cactus CVS
> 
> On Wed, 27 Mar 2002, Vincent Massol <[EMAIL PROTECTED]> wrote:
> 
> > BTW, is that something we want to recommend whenever possible ?
> 
> I'm not sure, especially when we are playing with the data itself, it
> makes it harder to do experiments or change things.  I cannot
> magically make Peter add <nag> elements to the excalibur stuff for
> example.
> 
> I'd only recommend this approach for people who actively follow Gump
> development.
> 

Yes, but it is the same for any API. There is a published interface. In
Gump's case it is the project's DTD. If you make additions that are
backward compatible with the published DTD then fine. However, if you
want to modify the published DTD, then like any library you need to go
through a deprecation phase and such ... 

I agree that keeping all the information in GUMP was making it very easy
to change any of it without even the knowledge of the project (like the
nag stuff). 

However, 2 trends :

- Gump is becoming more known every day and as projects start relying on
Gump they would like (at least some of them would like) to also manage
the gump descriptor so that they are in sync with their changes

- it seems to me that as we currently finding patterns in our project
build files and want to externalize grunt work to tools like Maven, we
need a way to describe the project's status info ("modern status file"
as Ken put it I think) and Gump's DTD can provide some of it (with
extensions as for example Maven requires a bit more information).

It is always the question of Central vs Distributed ... Honestly I don't
know which is better ... or even if there is a simple answer to that ...
Distributed almost always better from an architecture perspective (it
looks scalable) but is often much harder to manage/sync ... and thus
usually need stable standards (which loops back to your comment !).

All this to say that in the end I agree with you ;-)

-Vincent
 
> Stefan
> 
> --
> To unsubscribe, e-mail:   <mailto:alexandria-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:alexandria-dev-
> [EMAIL PROTECTED]>
> 




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to