I'd be happy to contribute. > I was wondering where do properties go to?
That I'm not sure what your question means may be enough of an answer for you. I try to map as many of the object properties as I can for retrieveRevisionDescriptor( ) but never write properties back to the filesystem - I'm not sure if there are any that I could write to the file system. It looks like I could write lastModified. Are there other properties of significance that I am leaving out? I set creationDate to the modificationDate b/c I don't have access to creationDate through java.io.File. I figure that's a better date than nothing. A couple open issues that I'd appreciate feedback on: 1. An issue I have been unable to resolve (and is perhaps related to your question) is that when I create a file through WebDAV, my WebDAV client (Win XP) does not display the file with its correct content length or modificationDate. If I force a refresh of the directory display, I see the correct values. Any thoughts on this? 2. Caching - it looks like slide uses ehcache. Is it possible to control the cache parameters? How? I find that my WebDAV client does not consistently pick up changes to the filesystem backing the store. That is, changes that take place directly on the filesystem. 3. Resource type for createObject( ) - see the javadoc comment in the SimpleFileStore implementation. Basically, I always create a directory in createObject( ) b/c I can't tell if the object is supposed to be a file or collection. Only once storeRevisionContent( ) is called do I know that the object is supposed to be a file - so I remove the directory and create the file with the content. This seems like an odd way to handle this but I'm not sure of an alternative. Alon On Tue, 07 Sep 2004 08:48:29 +0200, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > Hi Alon! > > This looks like nice work. I was wondering where do properties go to? Or > do you only map resource type, content length and dates as done in > SimpleFileStore (you seem to mix up creation and modification time there?). > > Anyway, wouldn't you consider donating this store implementation to the > Slide community? This way more people could benift and maybe contribute > to it? > > Oliver > > > > alon salant wrote: > > http://cvs.sourceforge.net/viewcvs.py/photospace/slidespace/WEB-INF/src/photospace/slide/ > > > > AbstractSimpleFileStore implements ContentStore, NodeStore, > > RevisionDescriptorStore, RevisionDescriptorsStore, no-ops most of the > > interface methods, and declares abstract those that you need to > > implement to get basic create/remove/update/delete for files and > > directories. > > > > CountdownStore presents nested directories 10 .. 1 and a file 0.txt in > > the directory 1. This structure is defined in code. You can get some > > funky things to happen by trying to change this structure through a > > webdav client since this implementation seems to support all > > operations but does not preserve state. > > > > SimpleFileStore is my effort to create a slide store that simply > > serves an existing filesystem directory. It's working with some minor > > issues that I'll get in to in a later post. > > > > I created a stripped down webapp to work on this stuff. You can check > > out the module "slidespace" following the instructions on > > http://sourceforge.net/cvs/?group_id=113626 right in to your webapps > > directory if you want to run the two stores. > > > > $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/photospace co slidespace > > $ cd slidespace > > $ ant > > > > Alon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
