If you're doing caching against GeoServer I'd be really psyched if you investigated doing cache cleaning against our versioning protocol http://geoserver.org/display/GEOS/Versioning+WFS
You should be able to have a caching strategy that checks the history to see what's changed, and then just download the diffs, instead of loading the whole thing again. So basically uDig would just do a 'check out' in sort of svn style at the beginning, and then would stay up to date whenever it gets online. The other option, which has had some work in OGC, is the geosynchronization stuff, a GeoRSS feed of changes, that could be subscribed to and used to invalidate the cache. I'm not sure if that module really made it in to GeoServer though. But in general caching of WFS, even with user defined cache invalidation, would be great. We'd be psyched to reuse in GeoServer at some point, to do smart cascading of other WFS's. Chris On Fri, Dec 19, 2008 at 10:37 PM, Jody Garnett <[email protected]>wrote: > Emily Gouge wrote: > >> > Hi Emily; I actually thing the SoC student did not complete the work. >> >> Do you have any more details about 'not complete'? >> > > How about not documented; and nobody has tried using it. > >> I can use it to cache things in udig without problems; however I don't >> know about cache cleaning policies and when the cache becomes invalid etc. >> > Fair enough; you are on a voyage of discovery. > > Emily >> >> >> Jody Garnett wrote: >> >>> Hi Emily; I actually thing the SoC student did not complete the work. I >>> would go ahead and take over the geotools module and do the work there. If >>> possible it would be nice to just focus on the production of a >>> CachingFeatureSource on the GeoTools side. >>> >>> Two ideas on what you could do with that: >>> - wrap the FeatureSource that your WFSGeoResource returns in a >>> CachedFeatureSource. This is something you could do based on a connection >>> parameter (the parameter would be ignored by the WFSDataStore; but noticed >>> by the uDig implementation); or >>> - make a separate GeoResource which is a friend of your WFSGeoResource >>> but has better performance characteristics .... although I do not think our >>> IGeoResourceInfo data structure has much information about latency etc.. >>> >>> Cheers, >>> Jody >>> >>> Emily Gouge wrote: >>> >>>> All, >>>> >>>> I'm looking for some advice on where to put some client side wfs caching >>>> code I'm working on developing. >>>> >>>> At the moment I'm looking into using the gt-caching module for the >>>> client side caching; however this being an unsupported module I don't want >>>> any code in uDig to rely on this module. I've been doing my investigation >>>> work in a separate wfs-caching plugin (I copied the WFS server and >>>> georesource and made a new "wfs-c" server / georesource ). But I think >>>> others may eventually be interested in this work so I'm wondering where it >>>> should go in order to share it. >>>> >>>> Thanks, >>>> Emily >>>> _______________________________________________ >>>> User-friendly Desktop Internet GIS (uDig) >>>> http://udig.refractions.net >>>> http://lists.refractions.net/mailman/listinfo/udig-devel >>>> >>> >>> _______________________________________________ >>> User-friendly Desktop Internet GIS (uDig) >>> http://udig.refractions.net >>> http://lists.refractions.net/mailman/listinfo/udig-devel >>> >> _______________________________________________ >> User-friendly Desktop Internet GIS (uDig) >> http://udig.refractions.net >> http://lists.refractions.net/mailman/listinfo/udig-devel >> > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel >
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
