>>> What I am proposing is that the GML2OutputFormat be engaged when >>> strict cite compliance is set. >> I would prefer to see the production choice be used for cite testing as >> well. Can you point me at what issues there are with the old gml2 >> encoder? I've had good success fixing it in the past. >> What about an environment variable telling the encoder which one to use? >> This way one can use GML2OutputFormat2 if he wants so. > Ha, try to run wfs cite tests with a regular database setup and have > fun. It took me a couple weeks of spare time to figure out all the > issues and fix them cleanly so good luck. > > The alternative is to not change anything and keep the old postgis db > around with the old encoder and pass the tests for that special case. In > which calling ourselves cite compliant would be a stretch. > > The whole point for me in this exercises was not to test our WFS > protocol, we have already done that, it is to test our backend > datastores against the variety of cases that the cite tests throw out. > > Anyways, I am curious if other people think the value add here is worth > the hit in performance. As I see it there are different situations in which people tend to use one or other QA factor as the main driver to choose a product. We can't deny speed is, even if a lame one compared to robustness, scalability, reliability etc, the easiest to assess and hence the most often talked about. I have seen a large gov agency wanting to spit out GML as-fast-as-possible. I think an organization delivering GML to the public will always find the bottleneck being the network bandwidth, while an organization willing to use WFS as the centralized data edition service in its intranet will want it to be really fast. But, that is to say, I'm very willing to agree with you on this, Justin, I certainly want to have the least code paths possible, a single (gt-xsd) tech in use for both gml2 and gml3, and am also willing to sacrifice some perf to obtain that. I just want to make sure the solution, even if a bit slowerd, do scale up, does not blow up resource consumption, AND I would love to sit down with you and research for an strategy in which we can a) incorporate a pull/push model for gt-xsd streaming and b) make it in a way that the underlying tech used for the low level IO is pluggable, such that I can as easily reuse all the infrastructure for binary xml streaming. In conclusion, and sorry if all that comments didn't actually add more value to the discussion, this is something I would really love to see on _trunk_, but have my reservations about changing the gml2 encoder in 1.7.x.
> My opinion is I have never seen GML as a format > built for speed, it is way too verbose, it requires the loading of an > external document to describe itself, etc... I am also curious to know > if anyone has actually chosen server software based soley on how fast it > spits out GML. >>> 2) XmlSchemaEncoder: I am proposing replacing the old 1.0 schema >>> encoder with the new one. The old one has no notion of schema >>> overrides, and quite brutishly builds up a big string buffer and then >>> spits out the XML. +1 Cheers, Gabriel >> Yes, works for me. >> >> Cheers >> Andrea > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
