Accessing Content in both Virtulization and Deploy modes

[jconnell]

Hello,

Thank you for producing this excellent product.  You all should be very proud of what you've produced!

We will be using Alfresco to manage series of large sites that contain both static and dynamic content.  One of the features we'll be implementing for these sites is scheduled content.  We have some questions about accessing the content under various scenarios, but here's some context first.  We've developed our current plan based on our research in these message boards and our own experimentation.

Current Plan:

* We'll use WCM spaces to manage servlets, JSPs etc and static, unscheduled content.
* We'll use normal spaces to manage scheduled content and have content copied to a production repository.  The production repository will be embedded in the site webapp instances.

Is there a seamless approach for accessing the scheduled content in both the virtualization server and in the live server?  We know the AVMRemote approach used in the sample website works well in virtualization mode, but what about when the site is deployed to an application server?  It seems as if we'd be better off interfacing with Alfresco's NodeService or perhaps its JCR implementation. 

Thank you,

Jim

[alexander]

Hi

Do you think it may be easiar / cleaner to create WCM sandboxes that will hold scheduled content, and then custom workflow (time or event driven) will move them over to Staging sandbox, from where they will be automatically propagated to runtime servers.

This will allow also to prevew scheduled changes at any time before they are deployed.

Thanks
Alexander

[jcox]

About the product… you're welcome.
We're very happy about the way it's coming out.

We've put a lot of love into this thing to hear words just like yours.  This is an ambitious project with a long-term perspective.  Clearly, data tends to hang around for a very long time, so doing it right really matters. Keep the feedback coming (good or bad).  We're committed to making an enterprise-level content management product that mere mortals can install, and that you don't have to force someone to use.   That said, there are a lot of things that won't make it into our upcoming release – I really wish we had time for them, but we don't;  that's always going to be the case.  We'll get there step-by-step.

Out of curiosity, what is it that's motivating you to put scheduled content in the non-WCM spaces?   If your primary goal is to create/deploy web-related content, you're probably better off just using WCM spaces for everything. You can still use workflow for scheduled releases.

Another alternative for those who want to deploy between a WCM-based staging area and a live site:  Alfresco's CIFS/SMB interface.  This presents the repository as a normal-looking file system… thereby allowing you to use tools like 'rsync' (or anything else that deploys files).   The performance of this filesystem-to-filesystem approach would be pretty good if you were using a WCM-space; otherwise, it might not be as viable.  The main advantage is simplicity.

For example, on Linux you could say:

/sbin/mount.cifs  //127.0.0.1/virtview    \
     /your-cifs-mount-point               \
     -o user=admin,password=XXXX,port=XXXX
‍‍‍‍‍

Then rsync from CIFS to the native file system on the live site.
On Windows, you could use something like WinSCP  (or rsync via Cygwin).
No fuss, no muss, no programming at all.


Background
Currently we have 2 different repositories under the hood:

   o  Non-WCM spaces are stored in Alfresco's original repository
   o  WCM spaces are stored within the new repository:  the "AVM"

The AVM can do a lot more than just host "WCM spaces".

For example, we are going to be creating tools for source code management around some of its SVN-like features (such as directory-level snapshots, and so on).  It will take some work to  get there, but that's the plan.  Speaking of that, we're going to start developing Alfresco using Alfresco as our source code management tool as soon as it's technically/logistically feasible. This is at least a few months in the future  (when we do this, we'll keep mirroring over to a read-only SVN repository for those who don't want to take a big jump all at once).

[jconnell]

Thanks for your thorough reply!

Originally, we were going to separate article content from WCM content because of the misconception that it'd be difficult to share articles across sites.  After looking into the AVM interface and reflecting a bit more, I see that I have at least two options for sharing articles:

* Layered Files to link an article from one site to another (I need to look into this more).
* Article Categories to aggregate articles on each site.  A given category could contain articles that span multiple sites.

I like the category approach because it would be simple to provide a nice user interface for the CMS users that allows them to pick the "sites" on which the articles reside.