One limitation is still that fine grained security management is not exposed in Share.
So modifying the security of documents and spaces which are managed through the repository (from Share) is not supported in 3.2r (should be available in 3.3).
But as Paul Hampton said, most users would use the predefined security applied to the repository (security inheritance can be used on the repository side to simplify the security management tasks in Share).

That means You can browse the ‘Sites’ space to change security settings via the (JSF) Explorer client.
As Paul Hampton said “You just need to think about the implications of any changes that you make”.

Today I have tested the new Alfresco Enterprise version (3.0 SP1) as well as the embedded Share application.

Firstly, my feeling is that this version is much more stable than previous 3.0 release (there were a lot of look&feel bug, especially with IE). I’ve done a few tests only regarding the collaborative features (like blog, etc) because I wanted mainly to test the distinct installation options (local or remote) between Alfresco DM and Share.

That’s a key feature for us, because we want to share the documents between our collaboration solution and our DM solution, but we would like also to have a clearly decoupled architecture to ease configuration/maintenance, but also give us the ability to better manage scalability.

I can say that it is very easy to set-up the 3 main architecture implementations mode. You have basically 3 possibility ; you can install:

1/ Alfresco DM and Share on the same Tomcat server (this is the default option). In this case both web application will run in the same JVM.

2/ Alfresco DM and Share can be installed on 2 separate Tomcat java application servers (on the same machine).

3/ Or you can install share on a distinct machine and connect it to the remote DM repository.

It is as simple as modifying a configuration file, because Share as been designed to be installed remotely. With the third option (the one we will probably choose in our compagny), Share is loosely coupled with the DM, and the communication is managed only through http based on the Alfresco web scripts (REST style implementation). These 2 separate servers installation mode allows to completely separate the collaborative and the DM solution. This improve the scalability of the global architecture, but you can still share the documents.

Indeed, if you create a new Site in Share, then it will appears automatically as a space in Alfresco DM: Company Home > Sites > MyShareSite > documentLibrary > rootfolderOfMyShareSite So the documentLibrary module of Share is directly exposed as an Alfresco node, and you can browse it’s content as any other space.

One limitation however in this release…It seems that documents that are uploaded in a Share site can be edited only from Share (and not from Alfresco DM application). It is clearly mentionned in Alfresco because the following message is displayed in the Alfresco web UI: “This space is managed by Alfresco Share. Please use the Alfresco Share application to work with content within this space and any sub-spaces.” However, I was able to lock and unlock Share documents from the Alfresco web UI, so editing seems to works even if the warning message is displayed…will have to do more tests.

So far tests are quite positive…so we will probably quickly do a proof of concepts with a few users to test if the new Share application can be used as a production service.