Putting the philosophical debate aside for the moment there are two things on the table here:
1) fast GML 2) cite compliance with a generic setup The current set up can't do both without a complete overhaul of the current gml2 encoder... which is what the gtxml encoder is. Also to stress the point, I only want to replace the encoder when cite is enabled which is what? 99% percent of the time? Does anyone in production actually run with cite enabled? Asking for the sacrifice of some speed in a 1% case in order to achieve much better testing and qa of many of our datastores does not seem like an unreasonable request to me. Gabriel Roldan wrote: >>>> 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 >> >> > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
