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

["Jorn Bettin" <jorn.bettin@xxxxxxxxxxxxxxxx>]

> > 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.

We have to be precise in our communication. There's a big difference between
(a) building domain-specific modelling tools and
(b) using such tools to specify applications.

I think we're saying to use Eclipse for (a). "Joe Programmer" will be
interested in (b), where you've got a very good point about providing a
web-based UI. The tools for (b) are generated from a set of templates.
There's no reason why we can't have one set of templates for (b) that
generate a web-based UI (i.e. what you call server side software) and
another set of templates that generates a UI that integrates with Eclipse. I
suspect that some things will be easier to do in Eclipse (rich UI,
integration with various other tools) and that the web-based UI will "just"
provide the core subset of functionality that is relevant - to say
effectively support a distributed software development process with onshore
and offshore teams.

Jorn

Jorn Bettin
jorn.bettin@xxxxxxxxxxxxxxxx
www.softmetaware.com
Tel  +64 9 372 3073 | Mobile +64 27 448 3507 | Fax +64 9 372 3534