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".
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.
>
> 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.
------------------------------------------------------------------------------
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
