-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nancy Wichmann schrieb:

Brian Vuyk wrote:

...

We have a master site that contains content (topical videos, in this case), organized by taxonomy.

...

We have two (and potentially more) subsites which we want to 'inherit' nodes from a certain taxonomy

Can you share the database? If so, then the publication is a simple matter. http://drupal.org/project/term_permissions might help.

Another possibility is to rethink your design. If this is basically segmenting user experience, there is a nice write up on DO on how to segment your site with Taxonomy Access Control.

Anything based on access control is going to suck wrt performance. I'd do something based on services. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAks8zAwACgkQfg6TFvELooTUAgCgh4RvwY6oMUMmdJmOQhhp98jB R7UAn0q5F/W42nJBqMgB8bBbvAdrcSDC =r8gG -----END PGP SIGNATURE-----

On Dec 31, 2009, at 12:40 PM, Nancy Wichmann wrote:

Hmm, how about using db replication with the replicas being secondary databases on the sub-sites?

Seems like overthinking/overengineering to me. Not that it's a bad idea -- surely a 10M pv/m site replicating 1,000 nodes/hr couldn't sustain the feedapi solution I posted earlier; but if that's the type of site you're working on you should have a staff of 20 you could consult on this ;) -D

On Dec 31, 2009, at 1:29 PM, Nancy Wichmann wrote:

Domenic Santangelo wrote:

...

Seems like overthinking/overengineering to me.

It was just a thought. There's no need to insult me. You could have stopped with what I quoted.

Nancy E. Wichmann, PMP

Ouch. You should learn (sooner rather than later, imo) that criticism of an idea isn't the same as a personal insult. It's an odd reaction considering that I criticized my own solution as unscalable. I thought it was clear that I was saying that a solution such as yours would be more appropriate than mine in a very large-scale environment (which I didn't get the gist that the OP was working on), but perhaps it wasn't clear. As to overengineering in general, I think Drupal as a whole would be in a much better place if we called each other out on it more often (imagefield+imageapi+imagecache+upload+cck required for images in a node, anyone?). Food for thought. -D

Domenic Santangelo wrote:

learn that criticism of an idea isn't the same as a personal insult I was saying that a solution such as yours would be more appropriate than mine My apologies for misunderstanding and overreacting. My only defense is a concussion a couple of days ago from not knowing how to walk in New England winters. :-(

overengineering ... much better place if we called each other out on it more often I have to agree with you on that point. Some of the solutions I see people post in the forums sound like they were proposed by Rube Goldberg (is anyone else old enough to remember him).

Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

On Dec 31, 2009, at 7:57 PM, andrew morton <drewish@katherinehouse.com> wrote:

On Thu, Dec 31, 2009 at 4:53 PM, Domenic Santangelo <domenics@gmail.com

...

wrote: As to overengineering in general, I think Drupal as a whole would be in a much better place if we called each other out on it more often (imagefield+imageapi+imagecache+upload+cck required for images in a node, anyone?). Food for thought.

Okay given that lead-in then I'll call you out on a factual error since upload is a core module and not needed in the imagefield+cck stack you outline.

I was just talking about the difference between what you get out of box (enabled) and what it takes to implement this basic feature. Since you mention it though, imagefield actually depends on yet another module, filefield, that superscedes core upload. IIRC, upload.module is disabled by default anyway meaning that at very least you have to switch it on out of the box if you go another route.

the image handling methods that dopry established have been tested and proven, that's why they're in core in D7.

I'm not arguing this point. Look, complicated (to the newbie) implementations are what pay my bills. It's in my personal best interest to keep things complex, and the fact that I've used these solutions scores of times means that a) they work well and b) I get to charge people to do what would be almost insurmountable -or at least impractical - for them to do themselves and is easy for me to do. However, Drupal's growth will - and I argue has been - hampered by usability issues for the beginner. I mean, seriously consider what a rank beginner has to go through to be able to do such a basic thing as putting a picture in a blog post in D6 and below! I'm stoked beyond belief that fields and images are in D7, for this reason. I used images as an example intentionally, because I think it's a salient example of building to meet engineering requirements and not user requirements. As a piece of technology, the image stack is a work of art; as a usable solution for a beginner, it's pretty rough. I guess the point I'm trying to make is that engineering should follow the use case, and I hope that we as contributors to the community can consider that. I hope I don't come off too harshly; like I said, my interests are best served by complicating things further :). But I love the vision of Drupal and the community and want it - us - to be as awesome as possible. D