Adrian Custer wrote: > A sloppy weekly meeting: > > 1) Nothing said against YourKit > So if we can write up a page in the developers guide, and manage to follow it - then it sounds like we have consensus (look ma no PMC needed). > 2) 2.2.0 good to go (except it doesn't compile right at this instant) > So I think we are back in the game right now: - ext/oracle removed - failed experiment - ext/go - out of the build, since it is not going to be completed for 2.2.x can we remove it? - ext/mappane - I have it working, not smoothly but it displays enough for right now
> 3) 2.2.0 still scheduled to go out after rgould's exams (unless you > decide to release before) > This date appears to be when? - Wednesday? If someone can try the mappane module before then it would be cool. > 4) WFS will be made permissive to incorrect requrests (but with some > mumbling) > Um I had this discussion with Richard (for WMS) and also with David for WFS ... For WMS we have strategy objects that we delegate to that implement the different policies defined by each specification. This practice allows us to define additional strategy object for specific service implementations that are have issues.... I would like to maintain this idea, if I can ask the code to be "pure" spec, all hacks/allowances isolated in a manner similar to WMS (or a subclass if that is too hard). So Richard mostly raised this issue, I just ask that we provide a technical solution to the problem to prevent permissive code from making the code base a mess. So time to contact the module maintainer; and I would love to see the design before giving this idea a thumbs up. > http://news.independent.co.uk/world/fisk/article1204432.ece > * FrankW is reading about Lebanon... > That is crazy stuff Frank... > <acuster> Would it be possible, in future releases, to somehow trim down > the geoapi released with Geotools > <acuster> to contain only the relevant modules? > That may be possible; but we can also pull an interesting trick I have seen in other projects, in our reference section only provide javadoc links to the packages that matter to us... > <acuster> I don't expect an answer, but am raising the possibility > <acuster> Done > Darn - caught answering yet again :-) > <rgould> so due to a recent bug issue in uDig, I discovered that the WFS > plugin in geotools explodes if it encounters a Capabilities document > that does not conform to the WFS specification > <rgould> the problem is that the part that was missing from the document > was not essential to use the service > <rgould> now > <rgould> a couple years ago, when I was implementing the WMS plugin, > James gasped in dismay as he realized I was permitting servers that did > not conform to the WMS specification to be accessed normally > <rgould> i would like to do the same to WFS > <rgould> (so we can access these broken servers) > <FrankW> rgould: ++ on permissiveness. > Um, only if the code can still be maintained ;-) > <rgould> I thought it might be a good idea to come up with a general > concensus regarding what to do when something breaks specification > :-) 1) isolate specification 2) create dialects (derrived from the origional specification) that allow for specific breaches of contract in a controlled manner This will be come more obvious when we have WFS1.0 and WFS 1.1 support. Cheers, Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
