Some weeks ago I installed an Alfresco Server for a factory. They had a production line with terminals based in Windows CE which only understood CIFS connections. Engineers designed assembling instructions in the office, produced a PDF and assemblers consumed them from production line terminal. In this case, CIFS is a must.
Besides the license discussion and which smb/cifs library to use I see a big challenge in separating alfresco jlan code from the desktop shuffle file / temp file mimic to support desktop apps behavior like ms-office or adobe apps with alfresco's node and metadata model. Today this is a huge unreadable bunch of code. With other words: where to plug in any other cifs library not to get all the problems again Alfresco had (and still has) in working on a mounted drive with desktop apps? Most dms vendors implement this kind of magic code on the client side but of course could be also implemented on server side if there's no client part.
I totally agree with you about the advantages of an Adobe Drive like CMIS connector. It's a pitty Adobe does no more support it. From a technical perspective it looked awesome: Java side was OSGi based if I remember right and it was extensible with own menus and even a complete new connector.
Though they do no more support it I hope Adobe someday and somehow provides their solution.
Anyway maybe with the available frameworks today it might no more be that difficult to implement an own Adobe Drive like solution:
- The most advancing task in my eyes is the native layer. With Java Native Runtime and some open source libraries it looks like there is no need to do anything native by ourself: One could implement a CMIS FUSE Filesystem this way.
- The next important thing would be the context menus in Mac Finder/Windows Explorer:
Liferay has build an awesome library which makes it possible to access the new FinderSync API via Java (called "liferay-nativity"). It provides implementations for Windows/Linux/Mac
Though there are for sure many other obstacles to overcome I think these two were the hardest. I could build a first runnable quick-and-dirty solution on Mac which mounts the Alfresco CMIS repository into a folder (lists folders, reads/opens files, lists versions in a context menu) in just some days (and I am a very slow programmer ).
And I saw another (experimental) implementation for Windows (leveraging Dokan) on Github.
Maybe this could be done in a community effort together with Alfresco?
Hi Sascha (I suppose you're shomeier@github),
your project sounds very cool and you should join with Alfresco Global Hackathon ;-)
Unfotunately the dokan support in Windows is very limited and if you manage to setup a team you should take an eye on capsulate the required services and layers to get your work reusable and flexible. A colleague already created a proof of concept on linux 4 years ago (with no CMIS in mind): GitHub - LotharMaerkle/alffs: A FUSE filesystem for the Alfresco DMS repository server. Maybe you can get some insides from this code?
Personally I would prefer not to use CMIS if your intention is not really to have a connector for CMIS since it is more expensive (server load and implementation efforts) and unflexible. Instead I would prefer a custom REST-API focused on this use case.
Another point is that a DMS paradigm will never be fully compatible with a filesystem connector since any temporary files, deletes and recreates shouln't be seen on the Alfresco side. A separate project and/or Alfresco should take care about this with a separate layer which translates real, local OS operations into alfresco repo requests. Learned from the Alfresco CIFS shuffle code nightmare I think this should be moved on the client side but if you want to get more control over events like "when file is closed" fuse may be the wrong layer for that.
Good luck and keep us informed!
Hey Heiko, Axel,
yes it is that github repo. Sry I forgot to include a link (or maybe I just thought it is not worth to mention because actually the tough work is already done by the libraries "javafs" and "liferay-nativity". I just wired these libs together ).
The Hackathon sounds great but it is already next Friday. With my current projects I'm afraid it is too tight for me to get some free time.
I never tried on Windows myself. I just noticed that Dokan seems to have somehow revived in 2016.
I actually hoped I never have to dig into these deep layers with C but if so the code from Lothar Maerkle seems for sure helpful.
To be honest the idea actually was to implement a CMIS Connector but the topmost layer allows to mount any type of Filesystem: Any implementation of the interface java.nio.file.FileSystem can be mounted (as a reference I always use the Google InMemory Filesystem implementation for testing/developing). I really loved this concept in Adobe Drive.
So an implementation which triggers an own proprietary REST-API might also be possible (though, even on Java-Side it is still not a piece of cake imho).
With CMIS also many other parties could benefit. I am trying to reduce the server load by requesting only minimal information (filter attributes, not including relationships if not needed etc). Also I am experimenting with some client side caching.
I am not yet sure about what kind of problems might arise when implementing a writing capability (currently I mount a ReadOnly FS). Are you talking about some kind of "staging" layer like in git clients: "Pushing" to the server should only happen on manual user action? Hmmm...this actually might make sense if a user is working on a file/object which has references to other files/objects. A user might want to push all these edits in a single transaction.
We're working on an AOS drive for Windows (based on WinFSP, much like Dokany) thats is supposed to be an alternative to SMB for Windows clients. As AOS is NOT based on JLAN server, we expect much better performances.
Suggestion or contribution are welcome:
I wrote a blog post describing the additional analysis and research we did, and our current roadmap for this feature:
I'm interested to get your feedback.