so a set of benchmarks would give you the chance to show that
TIMTOWTDI, and the trade offs that exist between them. That would be
pretty interesting to someone trying to compare frameworks.
That's where having simple tests that exercise one aspect of the
framework in isolation, as far as is
Daniel McBrearty wrote:
so a set of benchmarks would give you the chance to show that
TIMTOWTDI, and the trade offs that exist between them. That would be
pretty interesting to someone trying to compare frameworks.
I doubt that this is a simple list of features, but you are free to
prove me
completely academic at the moment, but it would be interesting to see
the benchmark comparison thing done properly. If it were, the way
would be to specify a set of application functions, let people within
the various projects implement them as they wish, then benchmark. I
suppose ...
so what
Daniel McBrearty wrote:
completely academic at the moment, but it would be interesting to see
the benchmark comparison thing done properly. If it were, the way
would be to specify a set of application functions, let people within
the various projects implement them as they wish, then
e ability of the app to parse the uri, and process it.
I think this is a bit too simple. We should probably look at usual kinds
of URIs used in applications here.
/
/foo/bar/baz
/foo/1/bar/2/baz/3/4
/foo?bar=baz
...and probably more...
Also, there should be more than one action. I
Daniel McBrearty wrote:
Personally, I don't care about templating and ORM benchmarks,
why not?
Well, templating benchmarks maybe, but for an ORM I just have the
feeling the larger factor is how you use it, not which.
--
# Robert 'phaylon' Sedlacek
# Perl 5/Catalyst Developer in Hamburg,
On Mon, 2007-01-15 at 13:24 +0100, Robert 'phaylon' Sedlacek wrote:
Daniel McBrearty wrote:
Personally, I don't care about templating and ORM benchmarks,
why not?
Well, templating benchmarks maybe, but for an ORM I just have the
feeling the larger factor is how you use it, not which.
