Wolf, > > > > The boilerplate code is quite typical of the standard OGR driver. You would > > need/want a shared connection among different OGRGMEDataSource ? That would > be > > the point of moving it at the driver level. Actually I've coded something > like > > that in the FGDB driver since there's a bug in the underlying SDK and you > > cannot open simultaneously several connections to the same datasource. > > 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. > > > > Another driver using OAuth2 or those GME concepts in a brother driver ? I > have > > some troubles imagining what you have in mind, not having dug myself into > the > > topic. > > > > 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 ;-) Even _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
