Justin Deoliveira wrote: > That comment was not targeted at you directly, it was targeted at > everyone, including myself who opened up the point of conversation. fair enough, so it seems like you have our bless on this. > > Gabriel Roldan wrote: >> Justin Deoliveira wrote: >>> Putting the philosophical debate aside for the moment there are two >>> things on the table here: >> What do my comments have of philosophical? Didn't I basically tell >> that whilst I understand andrea's concerns about speed I am willing to >> support this, but I just have some reservations about doing it in >> 1.7.x if for the general case due to lack of exposure of the new code >> to production conditions? >> wait a minute... reading the thread from the beginning again I see >> you're talking of 2.0 here... sorry I jut got the alarm on about >> 1.7.x, this seems totally fine for 2.0 to me as I already told. >> >>> >>> 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? >> I don't know. >>> >>> 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. >> yes, sounds reasonable to me, you're trying to get a better QA end to >> end by easily running cite against different backends >>> >>> 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 >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
-- 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
