Even, On Tue, Oct 29, 2013 at 10:04 AM, Even Rouault <[email protected]> wrote: >> I'm thinking that there is rarely any reason to separate the >> connections, except if, maybe we'd like to support multiple accounts, >> so that you can get table A using account A, and table B with account >> B. But then again why don't you simply give access to A for both >> tables? The way I see it we only need a single connection since the >> API is RESTful. > > That makes sense. I don't think that there is a real use case with connecting > 2 > different accounts within the same OGR process. But if you share connection > between data sources, you should make sure that the sharing at the driver > level > is thread-safe (mutex, etc...) since it is valid for 2 OGRDataSource of the > same > driver to be used in parallel in different threads. >
Aha! Thanks for the warning. :) This makes me think that it's not worth it. Debugging multithreadded apps is a pain XD I might make it into a separate OGRGMEHttp class or similar instead. I'm mainly interested in code encapsulation and re-use, but at some point it might be interesting to have the ability to query multiple layers in GME in parallel. But I'll leave that as a backlog item for the future. >> Yeah, something like that, can't get into specifics at this point. I >> hope we'll announce it soon, though. Again I want to prepare for >> what's coming,and looking for some advice on best practices. I hope to >> avoid realizing in 2 months that I need to refactor the >> OGRGMEDatasource fully, but otoh that's not going to be the end of the >> world, if I have to do it that way. > > OK. Well you're probably the one with the best vision of what can be shared > ;-) XD ;) yeah. I'll bring it up when I can. Thanks for the feedback on this so far! --Wolf _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
