Jody Garnett ha scritto: > Andrea Aime wrote: >> Sorry for the cold shower Jody, but GeoResource and the like are stuff >> for the "catalog" module which has basically received no discussion >> and it's not documented. > Fair enough Andrea; but this is the third implementation (GeoTools has > throw out two already) - the only way I am going to get this documented > to your satisfaction is to set uDig and GeoServer up to actually use it > - and this is what is happening.
Nope... this is not going to happen until we are satisfied it's good. Geoserver at the moment has no catalog usage whatsoever. Putting undocumented and untested stuff in main seems like a blitz to me, not the proper way to do things in a community of peers. Chris did not even knew the catalog stuff was there, and I only discovered it because coverage reports showed me a big package with no tests whatsoever. >> You cannot treat it as a given just because uDig uses it. > I treat it as a given as this is a need that both GeoServer and uDig > share (managing application resources - in a lazy fashion). The code has > a direct liniage between the two application and it behooves us to: > #1 share code so we have less to maintain on our own > #2 put it in a common library so others can benifit Due to lack of documentation I still don't see what it buys to Geoserver. And I still haven't had the time to reverse engineer it (and wont' have it for months). Just by having a cursory look at it (very cursory) I see no real advantage, just more code. >> Hacking is fun, but maybe someone wants to understand what you're >> doing too... where are the docs???? Where is the discussion on how and >> why this thing is better than the DataStoreFactories it tries to >> replace, but in fact apparently just duplicates (many methods in common >> between the factories and one of your service objects). > Andrea why don't we start that discussion - with your question about > Factories vs Catalog Handles > > DataStoreFactories are about connecting to external resources (they > *only* create a class after all). Both our real applications have other > needs: > - Manage Resources (ie instances) - previously the best adivce was to > storing DataStores as singletons! > - Be Lazy (describe the content before connection (title, bounds, > description,etc...), GeoServer tracks this information as part of its > configuration (simply not good enough for uDig, or even users - we all > expect this stuff to work "out of the box') I agree with both as a general need, but I need Chris to allocate time to study it if no documentation is around at all... Cheers Andrea ------------------------------------------------------------------------- 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
