On Mon, 11 Jun 2001, will trillich wrote:
> > At 08:59 AM 6/8/2001 -0500, will trillich wrote:
> > >which of the existing paradigms will the widget farm most
> > >closely resemble? and what are your expectations for tradeoff in
> > >functionality/modularity-vs-performance?
> >
> > 1) What do you mean by your first question?
>
> if i was going to minimize a future learning curve, i'd like to
> be able to jump aboard the widget farm already armed with
> knowledge of how to do something similar. if it's nothing at all
> like mason, but similar to axkit, then (if i expect to be an
> ardent fan of the widget attack) i'd be better off pursuing
> axkit. for example.
Actually I've just built a widget-type system for AxKit, though it's not
documented yet. I've sent a couple of posts to the perl-widget mailing
list about it, though I don't think AxKit is terribly popular with the
users there (but then I suppose you could say that about XML and Perl
users in general).
> > 2) I believe there is nothing being done in the widget farm that would
> > really hinder performance other than being objects with methods. Really
> > without a good object structure then a widget farm is wholly useless.
>
> you're definitely right, there. i'm just noticing that several
> templating methods add "molasses in january" effects to the
> rendering of some pages. of course, there may be more to blame
> in the instance of implementation, than in the implementation
> itself...
I think anyone expecting this stuff to be performant is kidding
themselves. I can get XSP pages back in about 100ms with the current CVS
AxKit, and of course that slows down with many connections. You always pay
for these kind of abstractions.
> thanks for your replies -- we're leaning towards axkit or mason at
> the moment--
Cool :-)
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
