Even, > > I don't know the GME API, so the following might be non relevant, but I'm > wondering why you couldn't keep the current connection logic. You would "just" > need to establish the list of vector tables from a "GetMapContent" request (or > whatever it is called) and you would instanciate the layers just as you do > currently by parsing the "tables" option. I'm probably missing something ?
That's actually a nice and elegant solution! :) I like it, it will keep things simpler and should result in less shuffling of code around. > > Is there a precedence > > for this type of configuration in any other driver? > > 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. So yeah basically trying to see if I could make the code more re-usable, and possibly optimizing. I'm not there yet, still implementing basic functionality, but I like to be one step ahead in my designs. > > 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. --Wolf _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
