Bet you had forgotten about this thread acuster :-) It has been on my hit list for a while... I am ripping the "catalog" package out of the main library into an unsupported/repository library so we can have a place to play (and so aaime can stop being upset when he trips over those classes).
I would treat the problem you describe below in the same manner as version control (or even your distributed version control). Grab updates to your wrapper in a controlled manner; and possibly maintain the history so you never lose information the end user has provided you. Jody PS. If you were looking into your shared version control systems as a cheap way to get a distributed geo respository going I will be impressed. > Hey all, > > Do any of you know of literature (docs/specs/...) discussing the issues > with wrapping non-repository based resources to look like a repository? > > Realistically we are always going to have to deal with data outside of a > repository such as files on local or shared file systems and databases > either local or over the networked. Nonetheless, we may want to wrap > those resources to interface with them as if they were in an actual > repository since that would let us have all our metadata correctly > linked. However this brings up an issue of having external modifications > occur to the resources in our wrapper without us being aware of them. > Repositories have the luxury of being able to guarantee a consistent > state since all actions on the resources must pass through the > repository system. > > I imagine I am not the first to start asking if there is some way to > integrate the two which would require a WrapRepository to be able to > regenerate its state information from scratch if there is reason to > believe the WrapRepo is out of date. > > Can anyone point me in interesting directions, > > thanks, > adrian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
