On Thu, 2009-09-03 at 12:47 +1000, Brent McArthur wrote:
> Hi People,
> 
>  
> 
> I’ve been exploring a little bit recently with the PUR and Forum
> modules + commenting. I get the impression these modules are
> relatively young is that right? 

That depends on relativity of the "relatively young" term :D 
The first commit on the Forum module pom is from March 2007 [1]
PUR is 5 months younger.

> 
>  
> 
> The STK demo site includes some examples around commenting but none of
> the rest. The forum module talks about sample pages, but none are
> deployed during the bootstrap process and I can’t even see them in the
> source...

The samples were temporarily removed because they visually and
conceptually didn't fit in the STK. They will be resurrected once they
are rewritten and fit in. If you want you can still checkout some older
version of the modules and get the old samples from there.

> 
>  
> 
> Has anyone actually used these modules in a commercial context or on a
> real life public site? Are they mature enough?

As you said the commenting is being backed by the forum module, so
anyone using STK and commenting is also using the forum. And yes, I can
think of some that are using it in real life public sites.
As for the PUR, I believe Will and few others were using it so the
answer is yes to that one as well.

> 
>  
> 
> Also, once we start to get into user generated content we enter the
> realm of synching clustered repositories. What’s everyone’s opinion on
> the solution to this? From what I can tell the easiest approach is to
> move to a MySQL database as the repository
> (http://wiki.magnolia-cms.com/display/WIKI/MySQL+Persistence) so that
> all public instances share the same repository. Does that work?
> 
As long as you use only one public instance you do not need to synch
anything. With 2 or more publics you indeed need to come up with the
mechanism for synching the content. Clustering your repo seems to be the
most convenient way to do so. Since Magnolia supports multiple
repositories, you can also cluster only the UCG (i.e. forum workspace)
and keep the rest separated. However when you opt for clustering you
should be also aware of few things:
- there is no redundant copy of the content in the cluster. You have
only one repo so if for some reason this should become corrupted, all
your public instances will be corrupted and you need to reinstall all.
- variation of the above - during the upgrades, you need to upgrade all
clustered instances at once so there's no way to do the upgrade without
interruption of services like it is possible with non clustered
instances.
- when activating the content, only one instance from the cluster has to
be set as a subscriber since the content will be available to all as
soon as it is delivered to one.
- unless setting up only partial clustering, all the instances will have
the exactly same configuration (which might or might not be desired).

Some slightly related reading: [2] [3] [4]

>  
> 
> Essentially there seems to be very little information available as to
> what is Magnolia’s preferred/recommended approach UGC in a clustered
> environment. 
> 
>  
> 
> Any thoughts/recommendations would be much appreciated!

[1]
http://svn.magnolia.info/view/community/modules/magnolia-module-forum/trunk/pom.xml?view=log#rev26844
[2]
http://weblogs.java.net/blog/rah003/archive/2009/04/magnolia_cache.html
[3]http://documentation.magnolia-cms.com/releases/4-1.html
[4]http://wiki.magnolia-cms.com/display/DEV/Concept+Caching+In+Clustered
+Env

HTH,
Jan

> 
>  
> 
> Cheers,
> 
>  
> 
> Brent
> 
> 
> 
> 
> 
> ______________________________________________________________________
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------


----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------

Reply via email to