[Pywps-devel] creating GRASS locations per default

[xianfeng song]

The grass has a very large community, a built-in grass environment
should be a great help to users who program grass-related wps process.
No doubt about pywps's compatibility with wps specification. The point
we discussed now is how to leverage pywps code as a state-of-arts work,
supporting other software as grass. Ludwig's suggestion is valuable. The
'built-in' likes a plugin, not a 'tightly binding' ware. It is expected
that pywps has a switch line somewhere to tune so that non-grass users
does not trigger grass setting.

Jachym did most scripts at a moment and understands well pywps
structure. Perhaps his following poster indicates the similar idea.

Regards,
Song

On 2006-11-11 23:01, Jachym Cepicky wrote:
> Ok, so I suggets:
>     
>         - if the process should work on temporary location, then
>             self.grassLocation=None
>           so "self.grassLocation" variable is defined, but not set
>
> Any objections?
>
> Jachym
>         
> On Sat, Nov 11, 2006 at 02:53:59PM +0000, Ludwig Max Brinckmann wrote:
> > At this point in time I would not spend too much thought on back-ward
> > compatibility. I think with some experience implementing services it is more
> > important to get things right. If the changes required are in some form
> > documented, it should not be an issue. Certainly not for me.
> > Ludwig
> > 
> > On 11/11/06, Jachym Cepicky <jachym.cepicky at centrum.cz> wrote:
> > >
> > >hallo
> > >On Sat, Nov 11, 2006 at 12:40:36PM +0000, Ludwig Max Brinckmann wrote:
> > >> I think there are two issues: one is to support the WPS specfication,
> > >which
> > >> will require temporary storage and this should be defined in a common
> > >way.
> > >> The other issue are the requirements of different back-end environments,
> > >> such as GRASS. A generic WPS framework should none of this built in, as
> > >it
> > >> weighs things down for those who do not need it.
> > >> I think we do agree on this.
> > >>
> > >> I would suggest abstracting GRASS support out into a base class for
> > >> processes that use GRASS, maybe as a mix-in class. Processes that use
> > >GRASS
> > >> would inherit from it, so all general GRASS stuff stays in one place.
> > >>
> > >> Such a base class could also be the model for other framework adapters.
> > >>
> > >> The way pyWPS is built it should not be difficult to achieve this.
> > >>
> > >> Ludwig
> > >
> > >No, this will be no problem. I'm just thinking on backward
> > >compatibility. With this change (and others planed), next release is
> > >going to be 2.0.0 :-/
> > >
> > >Jachym
> > >--
> > >Jachym Cepicky
> > >e-mail: jachym.cepicky at centrum.cz
> > >URL: http://les-ejk.cz
> > >GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
> > >-----------------------------------------
> > >OFFICE:
> > >Department of Geoinformation Technologies
> > >Zemedelska 3
> > >613 00, Brno
> > >Czech Republick
> > >e-mail: xcepicky at node.mendelu.cz
> > >URL:    http://mapserver.mendelu.cz
> > >Tel.:   +420 545 134 514
> > >
> > >
> > >-----BEGIN PGP SIGNATURE-----
> > >Version: GnuPG v1.4.2.2 (GNU/Linux)
> > >
> > >iD8DBQFFVeDcyKt0uAjU4I8RAikJAJ96thrMiFw+cBCBntxeGDxBh+xriwCgj4Qx
> > >xBbDy31Sh4ZdZ73l4ykrDhI=
> > >=bBCg
> > >-----END PGP SIGNATURE-----
> > >
> > >
> > >
>
>