Hi Kevin!
Thanks for the success report!
> One thing I that I *think* I see is that although the sites share the
> same code base, they each have their own set of database tables.
This is correct, it will create a database per site.
>
> If true, this makes a scalable Ning-like approach reasonably easy to
> do, but eliminates other "network of networks" approaches that use the
> site_guid of entities to create a level in which it is possible to see
> content from multiple sites at once.
>
> A bit disappointing but presumably it means that Marcus could do this
> without major changes to the existing Elgg core code.
>
> The presence of the site_guid implies that Elgg was designed from the
> beginning for a "network of networks" approach but for some reason
> this has never worked in reality.
>
> Or am I missing something, Marcus?
You're not missing anything Kevin :)
Doing multisite the way I have done here is a compromise, but I
believe it's a good one.
First of, doing it this way means - as you suggest - that we can
achieve most of what we want without extensive core code modification.
It also gives greater options for scalability, as well as increased
security and fault resistance through compartmentalisation.
From memory. the site_guid was put in very early on but we never
really got to building out the necessary functionality... I believe
it's still on the back burner so may be fully implemented in future (I
am aware of a couple of third parties looking into this although I
don't know how far they've got).
My itch didn't need networks in networks, which is another reason I
did things this way. Networks in networks do introduce other questions
- for example, how permeable do you make the dividing wall.
I've been thinking about this a bit, and I think that NinN's could be
better achieved through a wider mechanism of network federalisation -
this would let administrators decide what to make available, and not
limit you to federalising between "multisite" networks... all elgg
installs could work this way.
Marcus