Mailing List Archive

[Cherokee] [Re]: Feedback: Improving the quality of Cherokee's documentation
On Thu, 31 Jul 2008, Alvaro Lopez Ortega wrote:

> On 31 Jul 2008, at 18:57, Taher Shihadeh wrote:
>
> > * <8> Table with equivalent functionality (and hopefully a full
> > setup example)
> > to that of specific mod_* Apache modules.
>
> I don't think this is really interesting. Besides the support of the
> Apache de-facto standards we have nothing to do with it.
>
> Actually, many of the module types won't even have a match on the
> others architecture. In fact, what would we do? Would we compare a
> bunch of pseudo-XML text with a screencasts? It would not be fair!

I disagree, we might need to take another approach. Show bunchmarks based
on 'the equivalent' configurations. But also show competition!

So give a theme based benchmrks; Show how well apache/lighttpd/boa/etc.
performs in serving PHP files. And give the Cherokee configuration for
doing the same, with real numbers.

Although some cherokee handlers (for example mine) are more like small
applications (vs scripts in python/php) it might still be interesting to
show what we can do with Cherokee on a higher level and how easy it is to
do so.


Stefan
[Cherokee] [Re]: Feedback: Improving the quality of Cherokee's documentation [ In reply to ]
> Although some cherokee handlers (for example mine) are more like small
> applications (vs scripts in python/php) it might still be interesting to
> show what we can do with Cherokee on a higher level and how easy it is to
> do so.
For me personally, this is where I hope to find new power in the
cherokee community, small, specific applications, but that is my
opinion. The web is more and more getting a grid, with servers serving
their content as webservices that are then mashed up into specific
websites. Servers to serve websites are well capable of these tasks. And
personally, I don't care to much if a webpage renders in 2.8 or 1.4
seconds. But when I have a server that parses a 1 TB satellite image and
is able to generate a resulting 400x400pixel gif or jpeg in under 3
seconds, or take a bounding box of a 65GB geospatial database, generate
an image and return it in less then 3 seconds. When I can reach these
goals you will see me dancing ;-)

As I said earlier on, my goal with cherokee is to set up the fastest
mapserver available, put cherokee-mapserver-servers in a cluster and do
something similar to what google is doing with their google maps
satellite image and road maps.

I am no longer thinking traditionally in html/semi static (php) content
webservers, I need webservers that are specialized in serving XML, JSON,
GML, GeoJSON, KML and so on.. so we can connect them to all the
existing, regular, webservers around that can turn these beautiful
webservices into content that is of use to visitors.

In the meantime, I will focus on documentation!

Kind regards,

Milo

>
>
> Stefan
>
> _______________________________________________
> Cherokee-dev mailing list
> Cherokee-dev at lists.octality.com
> http://lists.octality.com/listinfo/cherokee-dev
>
[Cherokee] [Re]: Feedback: Improving the quality of Cherokee's documentation [ In reply to ]
On Thursday 31 July 2008 20:33:19, Stefan de Konink wrote:
> > > * <8> Table with equivalent functionality (and hopefully a full
> > > setup example) to that of specific mod_* Apache modules.
> >
> > I don't think this is really interesting. Besides the support of the
> > Apache de-facto standards we have nothing to do with it.
>
> Although some cherokee handlers (for example mine) are more like small
> applications (vs scripts in python/php) it might still be interesting to
> show what we can do with Cherokee on a higher level and how easy it is to
> do so.

I must admit I didn't think about these specific cases. What I actually meant with <8> proposal was that we should have some sort of quick reference to specifica tasks to allow easier navigation through the documentation. Something in the line of "I want to use mod_rewrite, how do I do this with Cherokee", which should explain briefly how to rewrite URLs and what module's docs should be consulted to have more specific details.

In my flawed reasoning, I assumed everyone knew what every Apache module did, so I suggested the name of the module as index of our quickref table.
But I guess it is much more logical to simply state the desired task to achieve, and then write the small sections I was thinking of.

I do think Stefan is right about the benchmarking thing, but I would rather leave that part for the website and out of the documentation. Mostly for maintenance reasons: updating this kind of comparisons takes time, and though we're talking about a complete rework of the documentation this should be a one time thing.
Hopefully in future releases the documentation will grow incrementally but without requiring a complete rewrite for every release.
--
taher at unixwars.com
http://unixwars.com