[xwiki-devs] [WebDAV] Issues on MacOSX (Temporary Files Not Supported)
Hi Devs, I've looked into the issues with webdav on MacOSX and following is the diagnosis: Finder(Mac) and other text editors on Mac relies a lot on temporary files / directories created just for the duration of their operation. These files usually start with a "." and can be easily distinguished from others. But ignoring these files does not help at all because they are needed for the proper operation of those applications. There for, we need to support them somehow. Approach 1: Store all of those temporary files inside user's session object - This doesn't work always because some clients (Nautilus, Redirector, Davfs) creates a new session for each and every request they make, so the information will not be persistent across different requests. Although some clients (Konqurer, NetDrive, DAVExplorer) keeps a single session open throughout their operation and they can support temporary files with this approach. Approach 2: Store the temporary objects (resources) inside a database table or file system - This can be complex to implement and will slow down the operations. Approach 3: Use an in-memory storage in a per-user basis and store temporary files there (Ex HashMap<User,Object>). This is quite easy to implement but we need to manage the temporary storage carefully. I have implemented and tested Approach 1 and I will convert this to Approach 3 asap. In the mean time, if you think there is a better way to do this, please let me know. Thanks. - Asiri PS: Some clients are aware of webdav protocol and they workaround temporary files themselves, these clients work fine oob. Note: Temporary files that need to be supported: .* (Unix like OSs) Desktop.ini (XP) Thumbs.db (XP) *~ (gEdit) *.swp (Vim)
Asiri Rathnayake wrote:
Hi Devs,
I've looked into the issues with webdav on MacOSX and following is the diagnosis:
Finder(Mac) and other text editors on Mac relies a lot on temporary files / directories created just for the duration of their operation. These files usually start with a "." and can be easily distinguished from others. But ignoring these files does not help at all because they are needed for the proper operation of those applications. There for, we need to support them somehow.
Approach 1: Store all of those temporary files inside user's session object - This doesn't work always because some clients (Nautilus, Redirector, Davfs) creates a new session for each and every request they make, so the information will not be persistent across different requests. Although some clients (Konqurer, NetDrive, DAVExplorer) keeps a single session open throughout their operation and they can support temporary files with this approach.
Approach 2: Store the temporary objects (resources) inside a database table or file system - This can be complex to implement and will slow down the operations.
-1 for this one.
Approach 3: Use an in-memory storage in a per-user basis and store temporary files there (Ex HashMap<User,Object>). This is quite easy to implement but we need to manage the temporary storage carefully.
I have implemented and tested Approach 1 and I will convert this to Approach 3 asap. In the mean time, if you think there is a better way to do this, please let me know.
I would prefer 1, but since it doesn't work for all clients, +1 for 3. You should consider an expiration mechanism, since otherwise this will grow indefinitely. Maybe you could use the cache module, since it is a generic temp storage. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Wed, Dec 10, 2008 at 7:19 AM, Asiri Rathnayake <[email protected]> wrote:
Hi Devs,
I've looked into the issues with webdav on MacOSX and following is the diagnosis:
Finder(Mac) and other text editors on Mac relies a lot on temporary files / directories created just for the duration of their operation. These files usually start with a "." and can be easily distinguished from others. But ignoring these files does not help at all because they are needed for the proper operation of those applications. There for, we need to support them somehow.
Approach 1: Store all of those temporary files inside user's session object - This doesn't work always because some clients (Nautilus, Redirector, Davfs) creates a new session for each and every request they make, so the information will not be persistent across different requests. Although some clients (Konqurer, NetDrive, DAVExplorer) keeps a single session open throughout their operation and they can support temporary files with this approach.
Approach 2: Store the temporary objects (resources) inside a database table or file system - This can be complex to implement and will slow down the operations.
Approach 3: Use an in-memory storage in a per-user basis and store temporary files there (Ex HashMap<User,Object>). This is quite easy to implement but we need to manage the temporary storage carefully.
I have implemented and tested Approach 1 and I will convert this to Approach 3 asap. In the mean time, if you think there is a better way to do this, please let me know.
+1 for 3 as I don't have much ideas. You should use the XWiki cache component in place of HashMap it support a generic eviction system with a maximum number of entry and a time to live for each one. You can also configure in details using the cache engine own configuration files.
Thanks.
- Asiri
PS: Some clients are aware of webdav protocol and they workaround temporary files themselves, these clients work fine oob.
Note: Temporary files that need to be supported:
(These are not temporary files but system/cache files meaning that it's not deleted when the operation ends...)
.* (Unix like OSs) Desktop.ini (XP) Thumbs.db (XP) *~ (gEdit) *.swp (Vim) _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (3)
-
Asiri Rathnayake -
Sergiu Dumitriu -
Thomas Mortagne