RE: [gmt-dev] evolving GMT in a fully open process that allows others to

["Ghica van Emde Boas" <emdeboas@xxxxxxxxxxxx>]

> yep - and this is why I proposed the feature matrix in
> my other mail....
Markus, are you going to start one? So that I can fill in the Fuut-je column
:-)

> > The GMT platform can play a very important role. By allowing
mix-and-match
> > of various transformation/generation components ...
>
> yes. and we need some kind of repository, right?
> Are there any plans?
The plans are to just use the file system, and use XMI or some other form of
XML as the content structure. If we would need versions etc. we could just
use CVS. Another suggestion (from Brian Barry) is to contact the Stellation
folks and see what they can do for us.

> > On the other hand we may not want "hard" dependencies on Eclipse and may
> > decide to create a plug-in architecture that is not tied to any specific
> > IDE.
>
> Disagree. If we do that, we'll start reinventing platform stuff, which is
> not our core business. We should, however, make sure that plugins
> do not depend on the GUI (Workbench) nececessarily. You can easily
> run the Eclipse platform infrastructure without the GUI as a "command-
> line generator".
How user friendly is that going to be? Our design point should be that "Joe
Programmer" will be able to use GMT and see it as a help, not a burden,
otherwise it will never catch on. I strongly believe that our tool should be
server side software, while the user should be able to use GMT from a
browser, at best with a browser plugin. I doubt very much that Eclipse will
provide help as server platform.

>
> > Suggest that we are not religious but pragmatic, i.e. we should avoid
> > reinventing infrastructure that has nothing to do with model
> > transformation/generation.
>
> ähm, yes :-)

I agree too :-)

Regards,
Ghica van Emde Boas
Bronstee.com Software & Services b.v.
e-mail: emdeboas@xxxxxxxxxxxx,
tel: +31 23 5474422,
or: +31 6 53368747 (mobile)
fax: +31 23 5473347 >