<div dir="ltr"><div>Nyall,</div><div><br></div><div>Thanks so much for this detailed explanation. Without it I probably would have taken the wrong direction and wasted a lot of time. QgsBlockingNetworkRequest is probably what I need so my development with this will assume user's have 3.6 or later. <br></div><div><br></div><div>Calvin</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 27, 2019 at 12:35 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 27 Nov 2019 at 15:26, Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> wrote:<br>
><br>
> Thanks Nyall for the precisions.<br>
> I wasn't aware of QgsBlockingNetworkRequest.<br>
><br>
> So basically, if I don't require authcf, then starting from 3.6 there is no reason to use my python nam, I should use both QgsNetworkContentFetcher and QgsBlockingNetworkRequest. And from 3.10 if require authcfg in QgsNetworkContentFetcher.<br>
> Is this correct?<br>
<br>
QgsBlockingNetworkRequest has always supported auth, so you should use<br>
that in 3.6 and above in all situations WHEN you need a blocking<br>
request.<br>
<br>
QgsNetworkContentFetcher is async, so definitely prefer to use that<br>
whenever you don't need a blocking request.<br>
<br>
I'd say the matrix is something like<br>
<br>
QGIS 3.4:<br>
<br>
Blocking:<br>
With auth: python nam (but be aware that it CAN and DOES crash<br>
crashes if used on the main thread)<br>
Without auth: python nam (but be aware that it CAN and DOES crash<br>
crashes if used on the main thread)<br>
<br>
Non-blocking:<br>
With auth: nothing available off-the-shelf -- roll your own<br>
using raw the qt and QGIS auth api?<br>
Without auth: QgsNetworkContentFetcher<br>
<br>
QGIS 3.6 - 3.8:<br>
<br>
Blocking:<br>
With auth: QgsBlockingNetworkRequest<br>
Without auth: QgsBlockingNetworkRequest<br>
<br>
Non-blocking:<br>
With auth: nothing available off-the-shelf -- roll your own<br>
using raw the qt and QGIS auth api?<br>
Without auth: QgsNetworkContentFetcher<br>
<br>
QGIS 3.10:<br>
<br>
Blocking:<br>
With auth: QgsBlockingNetworkRequest<br>
Without auth: QgsBlockingNetworkRequest<br>
<br>
Non-blocking:<br>
With auth: QgsNetworkContentFetcher<br>
Without auth: QgsNetworkContentFetcher<br>
<br>
<br>
Nyall<br>
<br>
<br>
<br>
><br>
> Cheers,<br>
> Denis<br>
><br>
> Le mer. 27 nov. 2019 à 00:27, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> a écrit :<br>
>><br>
>> On Wed, 27 Nov 2019 at 00:44, Denis Rouzaud <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi,<br>
>> ><br>
>> > Jumping late but we use the work from NAM Alessandro did in a couple of locator filters.<br>
>> > <a href="https://github.com/opengisch/qgis-swiss-locator/blob/master/swiss_locator/core/network_access_manager.py" rel="noreferrer" target="_blank">https://github.com/opengisch/qgis-swiss-locator/blob/master/swiss_locator/core/network_access_manager.py</a><br>
>> ><br>
>> > I believe I have done very very few adaptations/fixes to the original work and it works like a charm.<br>
>><br>
>> Not quite. It works in some circumstances, but it uses an event loop.<br>
>> So if you run it on the main thread, you're potentially doing an<br>
>> effective call to QApplication.processEvents, which can lead to all<br>
>> sorts of crashes. That said, it's generally a safe approach to use for<br>
>> QGIS <= 3.4... just don't use it in any code which relates to<br>
>> rendering!<br>
>><br>
>> ><br>
>> > I had in mind to bring this as is within QGIS core for some time. The main point being for us the blocking request rather than authcfg.<br>
>><br>
>> That's EXACTLY what QgsBlockingNetworkRequest is -- please don't<br>
>> re-re-implement this!<br>
>><br>
>> Nyall<br>
>><br>
>><br>
>> ><br>
>> > Denis<br>
>> ><br>
>> > Le mar. 26 nov. 2019 à 15:36, C Hamilton <<a href="mailto:adenaculture@gmail.com" target="_blank">adenaculture@gmail.com</a>> a écrit :<br>
>> >><br>
>> >> Thanks everyone. This gives me some good ideas. These are the possible solutions:<br>
>> >><br>
>> >> 1. Write a python implementation of QgsNetworkContentFetcher or QgsBlockingNetworkRequest. With this I could look at the QGIS version and if it is 3.10 or greater import the core method; otherwise, import the python implementation.<br>
>> >> 2. Use the old Boundless implementation if it still works in QGIS 3.<br>
>> >> 3. Use QgsFileDownloader and save it as a temporary file before processing.<br>
>> >><br>
>> >> Calvin<br>
>> >><br>
>> >> On Tue, Nov 26, 2019 at 2:29 AM Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> On Tue, Nov 26, 2019 at 8:22 AM Richard Duivenvoorde <<a href="mailto:rdmailings@duif.net" target="_blank">rdmailings@duif.net</a>> wrote:<br>
>> >>>><br>
>> >>>> On 26/11/2019 00.06, Nyall Dawson wrote:<br>
>> >>>><br>
>> >>>> > There's not. But there's the ex-boundless "networkaccessmanager"<br>
>> >>>> > implementation that supports authcfg, which you can find at<br>
>> >>>> > <a href="https://github.com/north-road/qgis-redistricting-plugin/blob/master/redistrict/linz/networkaccessmanager.py" rel="noreferrer" target="_blank">https://github.com/north-road/qgis-redistricting-plugin/blob/master/redistrict/linz/networkaccessmanager.py</a><br>
>> >>>> > (and other projects -- as far as I'm aware there's no real upstream<br>
>> >>>> > for this... Alessandro?).<br>
>> >>>><br>
>> >>>> I used this Boundless thingie for several plugins now (original source<br>
>> >>>> is now pointing/redirecting to planetlabs [0]).<br>
>> >>><br>
>> >>><br>
>> >>> Yes, that's the "upstream" but I don't know if that one is maintained anymore.<br>
>> >>><br>
>> >>> Btw, there is also a specialized class for sync/async downloads that supports authcfg: <a href="https://qgis.org/api/classQgsFileDownloader.html#details" rel="noreferrer" target="_blank">https://qgis.org/api/classQgsFileDownloader.html#details</a><br>
>> >>><br>
>> >>><br>
>> >>>><br>
>> >>>><br>
>> >>>> I think we already discussed several times that it would be good to<br>
>> >>>> incorporate this into a commons lib for QGIS. But if I'm correct the<br>
>> >>>> actual interface was not exactly what some wanted, and if I recall<br>
>> >>>> correct Nyall tried to pull this into c++ but hit some multithreading<br>
>> >>>> issues.<br>
>> >>>><br>
>> >>>> But as Nyall says: I think this is a great lib to use in a plugin (also<br>
>> >>>> because it used the QgisNetwork-stuff, so you can receive the signals<br>
>> >>>> from it or log the precise urls, like we do in the QGISnetworklogger<br>
>> >>>> plugin [1]<br>
>> >>>><br>
>> >>>> Regards,<br>
>> >>>><br>
>> >>>> Richard Duivenvoorde<br>
>> >>>><br>
>> >>>> [0]<br>
>> >>>> <a href="https://github.com/planetfederal/lib-qgis-commons/blob/master/qgiscommons2/network/networkaccessmanager.py" rel="noreferrer" target="_blank">https://github.com/planetfederal/lib-qgis-commons/blob/master/qgiscommons2/network/networkaccessmanager.py</a><br>
>> >>>> [1] <a href="https://github.com/rduivenvoorde/qgisnetworklogger" rel="noreferrer" target="_blank">https://github.com/rduivenvoorde/qgisnetworklogger</a><br>
>> >>>> _______________________________________________<br>
>> >>>> Qgis-user mailing list<br>
>> >>>> <a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a><br>
>> >>>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
>> >>>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> --<br>
>> >>> Alessandro Pasotti<br>
>> >>> w3: <a href="http://www.itopen.it" rel="noreferrer" target="_blank">www.itopen.it</a><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> QGIS-Developer mailing list<br>
>> >> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> >> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> >> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > QGIS-Developer mailing list<br>
>> > <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> > List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> > Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>