On 19 Feb 2008, at 11:49, A.D.F. wrote: > Stefan de Konink wrote: >> Alvaro Lopez Ortega schreef: >>> > >> I wonder something. Could you or maybe any other developer write on >> the >> website why Cherokee has such speed 'advantage' over other project, >> while the amount of features is still climbing? >> >> - From a public relations point of view it could be considered a Good >> Thing(tm) to make clear what internal features make Cherokee great. > > Well, right now Cherokee is very fast but it is not the fastest > webserver you can get; as everybody can guess, it is still evolving > wildly, > our aim is to improve it step by step and to keep it fast enough > even when new features will be added. > > The TODO file contains lists of new macro features, > grouped by major version, that are desiderable to be implemented, > of course some of them could be shifted to higher versions > (i.e. 0.8.x instead of 0.7.x, etc.). > > I have a personal TODO list that is filled with technical details > about "hot spots" that could be improved in future versions of > Cherokee, > but as this TODO list is rather rough I'll keep it private for now. > > From a public relations point of view, having a white paper > about why Cherokee is great in some tasks (or is not in many others) > could certainly help many people to understand > when and how to use it in a successful way. > > IMHO this kind of document could be written after 0.6.1 or even 0.6.2 > are released; Alvaro could say something more about this thing.
Well, that is not an easy question to answer, actually. From *my point of view*, even if we are missing some non-critic modules, Cherokee does the right thing where many others have failed. For instance, I would highlight: - Code quality I know that this is a quite subjective topic, but I invite you to read Cherokee source code, and then some other web server project source tree. If the price of having a .flv module at this time would have been to downgrade the source quality, I would prefer to simply miss it as we currently do. In the medium term we will have to handler, but our overall software quality and maintainability will be much higher. - Target: We have a crystal clear target. Cherokee ought to support the most widespread technologies and no more. It would not make sense to support a million things that average users do not need or use (and that obviously would have an impact on the performance). If the average user wants a certain technology we will work to have the best possible implementation, but we will not even try to implement "marginal" technologies or fancy extensions that in the medium could affect the server performance. - Experiments and tests We have done a hundred experiments and proofs of concept so far (and "a hundred" may not be as overstatement). Most of them are now gone, but a few of them have survived and are part of the main tree. Things like the maintaining mode for rotating the server logs without a single millisecond of downtime, the remote administration and tweaking mechanisms, and many of the internal designs are ideas that have born within the project. >> I think this is definately a section that lacks in the FAQ or Learn >> More. > > Yes, an updated FAQ section would be useful. We have to rewrite it almost from scratch, actually. The new documentation system that Brian committed is now working like a charm, so we have to get rid of the old documents and start using the new system. So far I have written some user and technical documentation (/cherokee/trunk/doc), but we should continue improving it for the imminent 0.6.0 release. The FAQ sounds like an important document. > What about starting posting a few (new) general questions > about Cherokee ? +1 -- Greetings, alo. http://www.alobbs.com/ _______________________________________________ Cherokee mailing list [email protected] http://cherokee-project.com/cgi-bin/mailman/listinfo/cherokee
