Gabriel Roldan ha scritto: ... >> FileDataStore interface would be implemented by >> data stores willing to help the directory data store (but >> it would not be required), and would have a single method: >> Collection<File> getFilesForType(String typeName) >> >> that returns the file that make up a certain feature type. >> This allows us to skip testing the .dbf, .prj, and so on, >> for a shapefile for example (if we do the shapefile datastore >> factory will actually accept them and create a new shapfile >> datastore, which is wasteful). > > That sounds just good. A question comes to my mind though. Did you take into > acount you'll have to pass the candidate DataStoreFactorySpi implementations > not only every file and directory inside the DirectoryDataStore's target > directory, but also the target directory itself? may be just a minor detail, > but was just wondering about that, since shp and properties are the only > working file based datastores I know of and the later would require the > "current" datastore URL as argument, as well as any subdirectory.
Yes, I know I have to pass the current directory along. But I don't understand your question... the property data store just takes a directory as the parameter, and I would pass that exactly... >> Check for directory updates: >> - use the last modified date of the directory >> to check wheter type name list should be udpated >> - if so, do again the scan. To try and avoid >> killing all already opened data stores, try the >> following: >> - check if any of the type map entries is linked >> with the current file, if so, we keep it > The missing situation seems to be that a file change may have changed the > feature type structure (say you replace states.shp by a new one with more > properties). But since I don't think that's handled by the delegate datastore > neither I don't see the point in bringing more grief to directory datastore > neither... or would it just be improper separation of concerns.... Right, it's the delegate datastore job to keep the feature type up to date. >> - if an existing entry file is gone, remove the >> entry >> - if a new file appears, create a new entry >> - to avoid redoing over and over the checks, maybe >> have a ds parameter that controls how often we >> check the filesystem for updates (and use a >> default value of 1 second). If we do this, have >> a method to force the update of the cache too. > It would be nice to abstract out the notification of filesystem changes into > some sort of callback mechanism instead of hardly tieing it to the custom > implementations. Rationale being that, to start with, we could use JPoller > (http://jpoller.sourceforge.net/). I guess JNotify > (http://jnotify.sourceforge.net/) is not an option cause even if it has de > desired functionality of direct OS notifications, it requires JNI. And in the > long term we could make use of JSR 203 to get notified by the OS directly > from > the Java platform (http://jcp.org/en/jsr/detail?id=203). > > Google also brings this class out > (http://geosoft.no/software/filemonitor/FileMonitor.java.html) which id LGPL > and may save you like an hour of coding :) Yeah, I guess I could use the last class, don't want to add dependecies to a dead project (last jpoller release is over 2 years old). Thanks for the pointers. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
