<div>Hi Barry,</div>"
you can't write data providers in Python". This is the point: I wonder if this is in absolute or it is in this moment. Given Qgis can load python and C++ plugins, I wondered if a similar thing could be achieved for data providers. I can imagine two ways:<div>
<br></div><div> - extend the data provider registry to load python modules and then extend the data provider class to make it call the data provider interface methods both on Python and C++ providers (doesn't the plugins loader/registry do something similar?)</div>
<div> - write a generic C++ data provider that acts as a proxy to the actual python data provider.</div><div><br></div><div>I don't know how hard it would be, but I can't find any technical barrier...</div><div><br>
</div><div>My use case are two.</div><div>One is to have "dynamic layers", in the sense I explained in a previous email. Let's say I have some code that does clustering on some data source. I would like to expose it as "live", meaning that it appears as any other static layer, but it's processed realtime.</div>
<div>The other is having the possibility to bridge, easily, any kind of data source, using python as an adapter.</div><div><br></div><div>giovanni<br><div><br></div><div><br><div><br><div class="gmail_quote">2012/8/29 Barry Rowlingson <span dir="ltr"><<a href="mailto:b.rowlingson@lancaster.ac.uk" target="_blank">b.rowlingson@lancaster.ac.uk</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have a vague memory that the python data provider idea was<br>
considered a while ago. I was thinking about how one could get direct<br>
access from Qgis to R spatial data sets stored in R's binary files.<br>
One method would have been to write a provider in python that used Rpy<br>
to bridge to R, but wasn't possible because you can't write data<br>
providers in Python. It could be done in C by linking to R's C<br>
library, but at that point I lost interest and used a looser coupling<br>
to get my R data into Qgis.<br>
<br>
The argument then went that if the provider was designed to access a<br>
file it would be a better idea to write a GDAL/OGR driver, then even<br>
people outside QGIS could use it. Obviously that would have to be<br>
C/C++ though.<br>
<br>
And then I think everyone got bored and went back to doing things.<br>
<br>
Do you have a specific use-case?<br>
<div class="im HOEnZb"><br>
On Wed, Aug 29, 2012 at 8:01 AM, G. Allegri <<a href="mailto:giohappy@gmail.com">giohappy@gmail.com</a>> wrote:<br>
> Anybody interested in developing the concept and evaluating its feasibility?<br>
> I'm considering the possibility to sponsor it.<br>
><br>
> giovanni<br>
><br>
> Sent from Nexus<br>
><br>
> Il giorno 28/ago/2012 00:11, "G. Allegri" <<a href="mailto:giohappy@gmail.com">giohappy@gmail.com</a>> ha scritto:<br>
>><br>
</div><div class="HOEnZb"><div class="h5">>> AFAIK it isn't possible to register a python script as a dataprovider.<br>
>> Maybe it sounds odd, but I think it would interesting if we could have it.<br>
>> Has it been ever considered? How hard would it be to implement it?<br>
>><br>
>> Giovanni<br>
>><br>
>> Sent from Nexus<br>
</div></div></blockquote></div><br></div></div></div>