Forum OpenACS Development: Reactivating oacs-dav with file-storage?
The combination of these two packages is really unbelievable. It could replace Dropbox and a few other Internet services in a closed-organization environment.
I've checked the OpenACS 5.9 version and tried to install it, but there were some very basic errors.
I'm not sure how this happened, but I'd be very interest to reactivate the package. Are there any important reasons why it shouldn't? Would somebody be willing to explain past issues and maybe help to overcome the first obstacles?
It seems you got similar issues that I got when I tried to install the latest version available OACS-5.9.
Then, I ran an earlier version (i.e. OpenACS 5.4.1 ) and the errors were gone. Of course, you will have to fix some bug, but at least I got a better scenario from there.
Also, I don't know all the issues are the same, but i advise to give it a shot. It worked to me.
Hope it helps,
In the meantime everybody is more than welcome to have a look at the previous oacs-dav implementation. We know it could need some reworking and that its current state is unclear, but is there for every brave spirit.
One thing I would not suggest is to just stay with an outdated version of the platform just to achieve webdav functionality. Seems like some regression happened, but could not take too much work to solve it on a current instance. I may give a hand in case, but I would at least need some log output for a starter.
To our current knowledge, these seem to be OK:
- CyberDuck: https://cyberduck.io/ (open source)
- WinSCP: https://winscp.net (open source)
- davfs: http://savannah.nongnu.org/projects/davfs2 (open source)
- gvfs through Nautilus or other Gtk-based file managers: https://wiki.gnome.org/Projects/gvfs (open source)
- Total Commander for Android: https://www.ghisler.com/android.htm
Native Windows webdav client is not working, at least for the Windows 7 version. The foreseen amount of work to fix this appears unfeasible at the moment.
Native MacOS client (tested the "El Capitan" version) is partially working, meaning that basic functionality is there with some glitches that sometimes prejudicate user experience. This, togheter with some serious scalability issues, moves much forward the time for an acceptable support (at least from us).
I didn't have the chance to test any mobile Mac device.
Resuming, it could be possible to give some decent webdav support to a fairly broad number of OSes, but one should not expect universal functionality in every case and with every client. Also, one should carefully evaluate the impact of the introduction of such a feature on a busy system, as the mindless copy-paste of a big folder by a user could hammer the system with many big requests.
The initial release will probably limit by a parameter the range of clients we intend to support to whatever degree. One may tweak it at his/her own risk, but then should be prepared to report bugs alongside a working patch! 😊
As stated several times, one problem with WebDAV is, that the various WebDAV clients built into several systems behave differently and even for one OS, these are moving targets. I've implemented in the past a fairly broad WebDAV support for OpenACS (5j ago), working for the Mac/Windows/Linux clients of that time, which was used by several groups in the learn@WU-system, but as we are a large organization, people use various versions of Windows/Mac-OS X/... various problems popped up due to changes bundled with the OS versions (people using older/newer versions of the OS, one has to configure the OSes with registry entries to work at all, etc.). Furthermore, problems popup up in complex cases, when user drag large folders, causing easily several hundred backend webdav queries for a single drop operation, which is a pain to debug.
... so, maintaining WebDAV is very costly. If the main goals is to upload many files with a single drop operation, one can use drop-zone in the xowiki menubar - with does not have the issues mentioned above.
Thanks! Good to know.
In the next version of ]po[, a priority will be the management for files related to projects.
However, a Web GUI is not enough for most Microsoft users. So my idea was to provide them with both Web and WebDAV access to "their" files, using the ]po[ project permissions to control access to files in a slightly modified file-storage package.
So we could limit access to WebDAV to Windows 7, 8 and 10 built-in clients. That would cover >90% of all potential users. Other users would need to receive an error message...
If I understand you right, this idea is basically unworkable, is that right?
I've recevied email with comments about oacs-dav:
- From Dave: There was a thread in February: https://openacs.org/forums/message-view?message_id=5348430 recommending to use the repository on SourceForge.
- From Iuri: The OpenACS 5.4.1 version of oacs-dav worked better for im.
@Gustaf: The funny thing is that file-storage has a dependency on oacs-dav, so it needs to be installed on basically every OpenACS system...
One could also find something that has the same level of transparence of a "real folder", as e.g. davfs2 for linux http://savannah.nongnu.org/projects/davfs2 (this also seems to work with our code)
On my windows 7 vitual machine I could no connect the native webdav client not even with my owncloud, so it is some task indeed!
Another thing we did was setup poatgresql based SFTP authorization from the openacs database with an external file storage location for the content repository and a trigger to add items to the database. You'd have to explore the security implications of that a bit.