jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject Re: Alfresco + Jackrabbit
Date Fri, 13 Oct 2006 12:30:48 GMT
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...


Mime
View raw message