David Nuescheler wrote:
Hi Robert,
Actually one thing that I find really interesting about Alfresco - in
case anyone wants to implement it as an add-on to Jackrabbit - is the
CIFS layer which supposedly allows good access to the server (as a
document server) from Windows clients. I would imagine that using
the jCIFS library it would
be possible to write something similar for a more generic JSR-170
provider...
I think this would be a good idea too, as a matter of fact we already
looked into the feasibility of something like that and it seems to work
just fine. Some random access performance drawbacks if we want
to keep it strictly bound to the JCR API.
jCIFS though is a CIFS client, right? At least I have not found a CIFS
server other than Starlasoft's / Alfresco's?
Am I looking in the wrong place?
Well the other question is the relationship between Starlasoft and
Alfresco, as the developer that is behind Starlasoft is on Alfresco's
payroll. What is not entirely clear is if the product on Starlasoft will
continue to evolve or if JLAN will become an integral part of Alfresco.
The license of JLAN inside Alfresco is Mozilla-based, with a strong
advertisement clause. But the advertisement clause concerns mostly GUIs,
and how does it apply to server-side libraries ? If JLAN is used as a
CIFS server for a Jackrabbit repository, where do you (and do you need
to ?) advertise the Alfresco copyrights, etc ?
Having tried mapping a WeDAV
location as a network drive I can say that it really doesn't work in a
usable fashion.
Really? So far I experienced a generally suboptimal perfomance
but it works just as well as CIFS for me, both on MacOSX and Windows.
What issues did you encounter?
Our experience with the WebDAV client on Windows has been nothing short
of horrible : two many buggy DLLs out there (see
http://www.greenbytes.de/tech/webdav/webfolder-client-list.html for a
detailed list of the bugs and implementations) and they all behave
differently. Caching is erratic, internationalisation is very poor (some
operations like renaming a directory using non ISO8859-1 chars are not
even sent out to the server depending on the version of the DLL !). My
impression is that Microsoft does not view the WebDAV client as
important, and therefore doesn't really make a big effort to maintain it.
CIFS on the other hand is the main file-sharing system on Windows
system, and is actively developed and maintained by Microsoft. Of course
this also means that they can change the protocol and implementation as
they see fit, which is a problem for libraries like JLAN that must
constantly keep up.
One idea that would be interesting would be to develop a "custom" open
source "file-system" driver for Windows, that could use a transport such
as WebDAV. There are closed-source solutions like Xythos Drive that
already offer this, but having an open source one might be interesting.
The good side about having such an implementation is that it could
evolve seperately to Windows implementations of WebDAV. The bad side is
that it's a lot of Windows-specific work and might be tedious. But there
are success stories such as TortoiseCVS and TortoiseSVN, they just lack
the mapping possibility.
The ideal open source configuration as I see it for file repositories :
- Strongly integrated open source client on Windows (offering the
possibility to control versions, searches, check-in/check-out, locking,
etc...).CIFS and the default WebDAV Windows client don't offer these
features.
- JCR backends such as Jackrabbit.
Anyway, just some food for thought :)
cheers,
Serge...
