[Twisted-web] CPUShare-Twisted

[Andrea Arcangeli]

On Sun, Jan 22, 2006 at 11:33:56AM +0100, Lawrence Oluyede wrote:
> think it's wron and I don't know where one excludes the other. You can

I've never said one excludes the other, I say that unit-test should not
be mandatory, and if you should write the unit-test _after_ reviewing
the code, not before.

> Let me say that reading those kind of question I'm starting to think
> that Twisted it's not what you need in first place, so why bother
> rewriting your app N times or wasting your time here if Twisted is not
> what you need? I specifically refer to the question #5

I started to think the same indeed, especially the more time I spend
answering email like this one ;). However I still feel that it's quicker
to get things working with twisted in the short term, and given all my
founding are my savings I've to be dirty and quick (I can't pretend to
debug memory corruption or memory leaks with so little resources, so an
interpreter is a sane choice), but if I had more resources I could
afford not using it and it would be a lot faster and it would scale to a
larger number of users using the same hardware resources.

> That's my main concern. If you have stateless stuff and you do only
> sql queries, do you really need all the twisted power?

No my app isn't stateless, or I would be using the thread model too.
The very cpushare protocol is complex in the way it handles race
conditions and async event like disconnects, twisted makes life easy at
the expense of scalability. This helps getting things working quick. And
I use pb to attach the webserver to the cpushare server, this is why
it's confortable for me to use twisted on the web side too (I'm not
making queries to the db only).

But most people with simpler projects would be better off with threads
to write web apps. Infact twisted web already provides a model like
this, my mercurial export already use it, moinmoin also uses it. the
webserver it's twisted.web for both and they're threaded.

> I wish you luck but this clause terrifies me:
> "If the CPUShare-Twisted fork fails to be successful, CPUShare will
> stop using Twisted, so the use of this fork is at your own risk."

I wrote it to scare people indeed, I'm careful not to generate any hype,
you know what you get when you work with me. If you get on the
CPUShare-Twisted project it probably means you already had to maintain
your own set of patches for over one year, so joining efforts won't make
thing worse even if I decide to dump twisted from my proejct (I can
only tell that my twisted branch has solid backups and I can guarantee
an export will remain availble if things go wrong).

> If you have find time to write countless emails on this mailing list,
> to say that Nevow is ugly and slow, to whatever... why didn't write
> unit tests for patches and stop?

Even before you write the unittest you should fix nevow, and that's not
going to happen, it didn't happen in one year after I sent the first
performance bottleneck reports, it sure can't happen in the few hours I
spent writing these emails.

Plus it'd be terrible to waste time on nevow when Cheetah is already an
order of magnitude better and faster (IMHO of course).

> I don't understand the real point to your argues.

The point is: if you think the same way I think, if you've similar needs
to mine, switch to CPUShare-Twisted.