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.