alon salant wrote:
I'd be happy to contribute.
Great :)
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.
I see. I was thinking about random properties like meta data you can set with the PROPPATCH method:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_webdav_proppatch.asp
and well yes, I am a MS fan ;)
However, not big issue not to set them...
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?
I remember I had this problem as well, when I did another store implementation. What values are displayed? Zero? Maybe MS tries to store other properties, I seem to remember something like this... I am so forgetful these days...
If you really want to go for it, try and trace the WebDAV communication with the default file store and then yours with the same requests and look for the differences. I would love to do myself, but am a bit short of time right now :(
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.
AFAIK ehcache is only used by the JNDI store. The rest of Slide uses some custom transactional caching stuff. I understand your problem. The cache would need to know when the file system changes in order to refresh. I do not think there is a way to get this done. ehcache has an option to invalidate entries after a certain amount of time. This would ne nice for Slide's cache just as well. For now, if you really need to to pick up the changes disable global caching completely. To do this set the caching mode to "cluster" with parameter "cache-mode" in Domain.xml. The parameter must be set for the complete store like
<store name="tx">
<parameter name="cache-mode">cluster</parameter>
...
...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.
This sounds rather reasonable to me. If it works, keep it like this...
If you need any help, especially with issue 1, or are ready to contribute the store, let me know...
Thanks,
Oliver
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
