2014-09-06 12:50 GMT+02:00 Martin Dobias :
> Hi Alessandro
>
> Finally I had some time to look at your proposal (your mail and the
> proposed QEP [1]). I am not that much involved in the QGIS server
> development, but the Python word in the thread subject always draws my
> attention :-)
Hello Mar
Hi Alessandro
Finally I had some time to look at your proposal (your mail and the
proposed QEP [1]). I am not that much involved in the QGIS server
development, but the Python word in the thread subject always draws my
attention :-)
On Thu, Aug 28, 2014 at 7:49 PM, Alessandro Pasotti wrote:
>
>
Hi Luca,
Thx, now I undrstand better.
You say the procedure pywps use a new temporary location for every new user.
At the end of the procedure the last action of the procedure is remove
the location.
If the procedure was killed for a timeout. No problem.
Every new use has a new location so no prb
2014-08-30 14:17 GMT+02:00 aperi2007 :
> As example:
>
> if apache kill a procedure that use grass.
> The grass is istantaneosuly killed. And this mean it leave a lock file in a
> own folder.
> If an user don't remove it (the file) the grass don't restart correctly.
>
> A.
Hello Andrea,
PyWPS can
Yes I think to him when say need a timeout procedure.
The Apache KILL is absolutely brutal and is better avoid to run in it
when there are connections to dbms or
opening of files.
Expecially if the procedure (qgis , processing, grass, and so on..) are
not think to work in a situation where
th
2014-08-30 13:28 GMT+02:00 aperi2007 :
> Another question could be the timeout.
>
> Infact. If a processing take too much time to end.
> It should go in timeout.
> So not only concurrency need, but also a timeout system to avoid the lock
> never ending of resources.
>
This is normally done at the
Another question could be the timeout.
Infact. If a processing take too much time to end.
It should go in timeout.
So not only concurrency need, but also a timeout system to avoid the
lock never ending of resources.
A.
Il 30/08/2014 13:21, Alessandro Pasotti ha scritto:
2014-08-29 18:05 GMT+
2014-08-29 18:05 GMT+02:00 René-Luc Dhont :
>
> Le 29/08/2014 16:54, Alessandro Pasotti a écrit :
>
>> 2014-08-29 16:39 GMT+02:00 René-Luc Dhont :
>>>
>>> Hi Alessandro
>>>
>>> Thanks for this interesting input.
>>> I'm happy to test it and to develope some use case.
>>> I thought it's a good featu
Hi Jürgen,
On Fri, Aug 29, 2014 at 4:08 AM, Jürgen E. wrote:
> Hi Pirmin,
>
> On Fri, 29. Aug 2014 at 10:24:00 +0200, Pirmin Kalberer wrote:
> > This looks like the first real case for an RFC! I'm quite sceptical
> adding
> > Python to QGIS server. In my opinion this should be discussed thorough
2014-08-29 18:05 GMT+02:00 René-Luc Dhont :
>
> Le 29/08/2014 16:54, Alessandro Pasotti a écrit :
>
>> 2014-08-29 16:39 GMT+02:00 René-Luc Dhont :
>>>
>>> Hi Alessandro
>>>
>>> Thanks for this interesting input.
>>> I'm happy to test it and to develope some use case.
>>> I thought it's a good featu
Le 29/08/2014 16:54, Alessandro Pasotti a écrit :
2014-08-29 16:39 GMT+02:00 René-Luc Dhont :
Hi Alessandro
Thanks for this interesting input.
I'm happy to test it and to develope some use case.
I thought it's a good feature and can help to enhance QGIS-Server easily :
WPS, WMTS, Table Join Se
2014-08-29 16:39 GMT+02:00 René-Luc Dhont :
> Hi Alessandro
>
> Thanks for this interesting input.
> I'm happy to test it and to develope some use case.
> I thought it's a good feature and can help to enhance QGIS-Server easily :
> WPS, WMTS, Table Join Service, WFS2 or other that OGC does not alre
Hi Alessandro
Thanks for this interesting input.
I'm happy to test it and to develope some use case.
I thought it's a good feature and can help to enhance QGIS-Server easily
: WPS, WMTS, Table Join Service, WFS2 or other that OGC does not already
know.
Regards,
René-Luc
Le 28/08/2014 14:49,
2014-08-29 15:13 GMT+02:00 Andrea Peri :
> Another question.
> Is about the security of the environment.
>
> I don't know too well the possibility of python in a qgis project.
> But I fear that a qgis project could have some python code to start ad
> startup of the qgis project.
> This mean that th
Another question.
Is about the security of the environment.
I don't know too well the possibility of python in a qgis project.
But I fear that a qgis project could have some python code to start ad
startup of the qgis project.
This mean that the same code should be run in the server when it start
2014-08-29 13:34 GMT+02:00 Marco Hugentobler :
>> A quick question: python plugins only add an #include and two lines of
>> code in qgis_map_serv.cpp, a #ifdef SERVERPLUGINS block should be
>> enough to disable them completely, where should I add that option to
>> let cmake know about it?
>
>
> You
A quick question: python plugins only add an #include and two lines of
code in qgis_map_serv.cpp, a #ifdef SERVERPLUGINS block should be
enough to disable them completely, where should I add that option to
let cmake know about it?
You can make an entries in CMakeLists.txt and in
cmake_templates
OS the python usable in a fcgi environment ?
This mean to load and lock an instante of python forma every fcgi session
(almost 40-60 afaik) ?
A.
Il 29/ago/2014 12:47 "G. Allegri" ha scritto:
>
>
>
> 2014-08-29 12:23 GMT+02:00 Andrea Peri :
>
>> The startuptime increase if iT should lo ad the p
2014-08-29 12:23 GMT+02:00 Andrea Peri :
> The startuptime increase if iT should lo ad the python environment.
>
> All the best.
>
The startup will happen only the first time, unless you use CGI and not
FCGI.
Anyway, I proposed it a couple of years ago, but many told it was useless
for various re
The startuptime increase if iT should lo ad the python environment.
All the best.
Il 29/ago/2014 12:13 "Paolo Cavallini" ha scritto:
> Il 29/08/2014 12:09, Andrea Peri ha scritto:
> > Hi Poalo,
> >
> > How you can say that the overhead should be minimal.
>
> Because in that case Python does alm
Il 29/08/2014 12:09, Andrea Peri ha scritto:
> Hi Poalo,
>
> How you can say that the overhead should be minimal.
Because in that case Python does almost nothing, just passing the command to
GDAL,
SAGA, GRASS, or whatever.
All the best.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS:
Hi Poalo,
How you can say that the overhead should be minimal.
?
:))
However surely best ifthe python on server is optional in compiling.
So if an user dont want it should remove it.
A.
2014-08-29 11:45 GMT+02:00 Paolo Cavallini :
> Il 29/08/2014 11:41, Andrea Peri ha scritto:
>> I guess the m
Hi Pirmin,
On Fri, 29. Aug 2014 at 10:24:00 +0200, Pirmin Kalberer wrote:
> This looks like the first real case for an RFC! I'm quite sceptical adding
> Python to QGIS server. In my opinion this should be discussed thoroughly
> first.
I recently spend some time exploring the server side expeciall
2014-08-29 11:56 GMT+02:00 Marco Hugentobler :
> Hi Alessandro
>
> Thanks for this interesting input. I'm happy to look at it in detail, but
> need a bit of time to review it and think about it thoroughly. Also I'd like
> to do some testing (e.g. run some of my internal server benchmarks here).
>
>
Hi Alessandro
Thanks for this interesting input. I'm happy to look at it in detail,
but need a bit of time to review it and think about it thoroughly. Also
I'd like to do some testing (e.g. run some of my internal server
benchmarks here).
As a fery first 2c: Python on the server can open som
2014-08-29 11:41 GMT+02:00 Andrea Peri :
> I guess the main goal is to avoid that the adopt of python on server
> could slow it.
>
> Infact , the main difference from a desktop and a server is that the
> first is serving only one perosn and this mean that the user could
> wait also for a work for h
Il 29/08/2014 11:41, Andrea Peri ha scritto:
> I guess the main goal is to avoid that the adopt of python on server
> could slow it.
Hi Andrea,
In the first case I imagine (executing Processing modules or models as WPS
services),
the overhead will be minimal, as all the heavy computation is run b
I guess the main goal is to avoid that the adopt of python on server
could slow it.
Infact , the main difference from a desktop and a server is that the
first is serving only one perosn and this mean that the user could
wait also for a work for himself.
Instead a server is used from many users and
2014-08-29 10:24 GMT+02:00 Pirmin Kalberer :
> Hi Alessandro,
>
> Am Donnerstag, 28. August 2014, 14.49:47 schrieb Alessandro Pasotti:
>>
>> as anticipated to some of you during the last HF, I've started to add
>> Python plugins support for the server side.
>>
>> The rationale behind server plugins
Hi Alessandro,
Am Donnerstag, 28. August 2014, 14.49:47 schrieb Alessandro Pasotti:
>
> as anticipated to some of you during the last HF, I've started to add
> Python plugins support for the server side.
>
> The rationale behind server plugins is doublefold: first they could
> provide additional
Hello,
as anticipated to some of you during the last HF, I've started to add
Python plugins support for the server side.
The rationale behind server plugins is doublefold: first they could
provide additional services without the need to touch the C++
codebase, second they allow for GUI-based conf
31 matches
Mail list logo
