I started with the Eclipse IResource: - http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/guide/resInt.htm
As you know there is a difference (in latency) between local and remote resources; one of the reasons we made up IGeoResource for uDig was so we could be really explicit about block behavior. However the ability of resources to get out of sync is still valid and there are some good ideas here on how to handle a number of issues (from associating properties with the resources so application writers do not mark up the code and have to tackle events and staying in sync, to the hole use of a handle object). The section on how "team" integration takes place (ie CVS or SVN) sounds like it relates to your question. - http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/guide/resAdv_hooks.htm - http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/guide/resAdv_refresh.htm In later versions of eclipse they tried to tackle the remote resources; allowing for resource like things to hang out in front of databases and remote resources. This is part of the navigator framework and not something I have looked into much yet. I get the impression (unfounded) that they part they have made common is on the user interface side (such as the "tagging" of content into working sets). For uDig we have a split between the LocalCatalog and the list of available Catalogs (If I can try using your language for a second: we have a local registry, which we have marked "searchable" and we have a number of other "searchable" things). Jody Adrian Custer wrote: > 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: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
