On Tue, Jan 24, 2012 at 7:41 PM, Justin Deoliveira <jdeol...@opengeo.org> wrote: > On Tue, Jan 24, 2012 at 1:56 PM, Gabriel Roldan <grol...@opengeo.org> wrote: >> >> Hi all, >> >> I'll be working on the wfs-ng module this and next weeks with the >> following high level goals: >> - port to ContentDataStore >> - have a single WFSDataStore implementation with strategy objects for >> the different versions, instead of one datastore per wfs version >> - make it share the http client code with the wms and wps modules >> - implement transaction support for wfs .1.1 >> - verify interoperability with a bunch of customer provided wfs instances >> >> Just ran into the question of what the earlier approach for "ng" >> modules was before they're ready to replace the "original" ones, in >> terms of connection parameter clashes. >> Do we prefer "ng" modules: >> 1- to share the connection parameter names with the old ones, so that >> they can be easily replaced > > > >> 2- to temporarily use some different parameter name so that both >> original and ng can be used at the same time, but fall back to the >> original connection parameter when it's ready to replace the old >> module >> >> 3- just use a different set of parameter names > > > The jdbc case was a bit different because of the "dbtype" parameter, which > was really what did the matching of parameters to factory implementations. > But I don't think wfs has the equivalent. ANyways, postgis for example, > during the deprecation phase of the old datastore tried not to interfere, by > only accepting "postgis-ng" as the dbtype. Once the old datastore was moved > to unsupported only then did the new factory take over and start to accept > "postgis".
Thanks Justin, that makes sense. So I'll follow that approach, letting them coexist until ng can replace, then it can take over the original parameter set. > > I suggest following a similar approach, which I think this your #2. >> >> >> Additionally, it just occurred to me that the datastore could be >> configured to use both a pooling http client (as the wms client can) >> and to fetch features from the upstream server using multiple threads. >> Default behavior would be to use a single thread. The old wfs 1.0 >> client forced spawning a new fetching thread per request, which didn't >> scale, so we had to avoid that. I'm thinking a more modern approach >> could be taken though, in order to have a fixed number of threads that >> hit a given wfs server, and still get some performance improvement by >> allowing a single request to use multiple threads to fetch contents, >> as long as the upstream server supports paging. I'm not committed yet >> to do that,but feedback would be much appreciated. > > > Makes sense... WFS is exactly built for speed as a protocol so i imagine > that threads will spend a lot of time waiting on I/O anyways... an > asynchronous approach probably makes more sense. yup, lets see if something good comes out of it. I'm sure there's a lot of good literature on how to do that well. Anyways, not a requirement, just on the wish list. Cheers, Gabriel >> >> >> TIA, >> Gabriel. >> >> -- >> Gabriel Roldan >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
