Matt Sergeant wrote:
>
> On Fri, 27 Oct 2000, Tim Sweetman wrote:
>
> > In no particular order, and splitting hairs some of the time...
> >
> > Sounded like mod_backhand was best used NOT in the same Apache as a phat
> > application server (eg. mod_perl), because you don't want memory-heavy
> > processes sitting waiting for responses. You'd be better off with a
> > separate switching machine - or serve your static content from
> > machine(s) that know to backhand dynamic requests to a phat machine. I
> > think that's what Theo reckoned...
>
> Yes, but the backend mod_perl servers are running backhand. So you have:
>
> B B B B
> \ | | /
> \ \/ /
> \|/
> F
>
> Where all the servers are running mod_backhand, but only F is publically
> accessible. There may also be >1 F. Its in his slides, and is prettier
> than the above :-)
Yeah. I know how it was set up in Theo's demo (like that) but I got the
impression that this wouldn't be optimal for a mod_Perl setup (or other
big-footprinted configuration). You _can_ run mod_backhand on your
content servers. You don't _have_ to.
> > "make simple things easy, and hard things possible" -
> > What concerns me about systems like AxKit & Cocoon is that they may make
> > simple things complex, and some hard things possible. But this is a
> > naive comment not based on trying to build rilly big systems with them.
> > Perl, maybe, doesn't make simple things anything like as easy as PHP.
> > (Again, a naive comment that may be incorrect)
>
> No, its correct, I think. I'd like to maybe next time do the second half
> of the AxKit stuff as a Demo, but that takes some demo-able material thats
> actually going to make you say "Ooh, that *is* easier than what I'm using
> right now". So I'll work on it :-)
One thing I have my eye on (which doesn't mean I'll necessarily get it
done :) ) is some sort of data-holding-class that sits between an
application and a template in a transparent way (eg. it could hold the
method names & args that you were passing to a templating system, like a
"command" design pattern IIRC). This would potentially allow:
+ switching between different templating systems ...?
+ checking out template tweaks without rerunning the app - good for
"interactive" systems which
keep chucking form data at users
+ (fairly transparent) conversion to XML/XSL/etc at an appropriate time,
as/when/if a site/project
grows to an appropriate size
> > And at Apachecon, the XML guys say: "This Document() function's really
> > cool! You can build a portal very easily..." And after falling asleep
> > (reflex on hearing /portal/, marketing allergy) I thought, it's
> > syndication/transclusion again. Evidently, a big idea. But a big idea
> > buried in a heap of other big ideas.
>
> Its all been done before. I spoke a bit to Rael Dornfest about P2P (Rael
> is an O'Reilly guy behind the P2P summit). Basically its all the same
> stuff we've already been doing, but its just a buzzword. But it often
> takes buzzwords to make the world sit up and take notice and focus on the
> right thing to be doing, even though they may not know it themselves!
Panics are also good for that, eg. only way to get people to fix y2k
bugs seemed to be to claim imminent catastrophe.
--
Tim Sweetman
A L Digital
"I'm pushing an elephant up the stairs" --- REM
