On Tue, Jan 24, 2012 at 9: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
>
Nice. How are you going to deal with all the xml parsing/encoding required?
>
> 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
>
I agree 2 is probably the best way
>
> 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.
>
Sounds like a cool optimization, at the same time I'm wondering how much
impact it will actually have. Rationale:
- relying on paging it will work only against WFS 2.0 official
implementations,
or on WFS 1.0/1.1 vendor extensions. You did not mention WFS 2.0 above,
is that going to be implemented as well?
For vendor extensions, how do you recognize them? And how do you deal
with the issue of the first record being 0 or 1 depending on the
implementation
(GeoServer uses 0, MapServer uses 1, the spec is not clear)
- parallel requests will actually speedup things only if the bottleneck is
the CPU
and/or if each request is bandwidth capped, so that if you make parallel
requests you either get more CPU power or more total bandwidth
I agree it could be an interesting optimization for some cases, at the same
time making a truly interoperable client, that deals with WFS 1.1 servers
not flipping the axis as they should, usage of non EPSG codes (ESRI)
and so on, will be a "lot of fun" already :-)
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
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
