Hi!
Maybe the way forward is not to talk about what is the best thing -
but rather about the design choices being made. My hope is that when
we spell them precisely we'll see the tradeoffs involved and it'll be
easy to see why different situations call for different sides in these
tradeoffs.
Ok, i'll have a go at it regarding my Maplat framework:
The basic design goals weren't initally to design a stand-alone framework but
to design a developement environment for some in-house projects (it was in the
middle of this process that i was able to get most of it open sourced).
The design requirements where to provide software for automating certain tasks
like a just-in-time booking system and a chipcard solution. All software should
be controlled by a web interface, using worker processes for long-running
background tasks and everything should be stored in a database.
Security - apart from a basic username/password login - was of no concern, as
all software would only be reachable on the companies internal website (abuse
would be delt with by the human resources department).
On the other hand, low level control over everything the framework does WAS a
design criteria, which includes having the ability to quickly hack in
workarounds for browser and proxy bugs (which includes sending "broken" replies
in some cases) and so on. To clarify: This isn't an up-to-date office network
but a production plant - meaning production lines with PC's strapped on. Most
of the computers run the operating system they originally came with (some
production lines are > 8 years old, meaning Windows 98, NT and 2k) because the
hardware control software can be upgraded without MAJOR production outage.
In difference to many other projects, the "Web" part of the framework is only
one aspect of the whole. It is basically just a way to provide a GUI to the
background workers - communication between workers and GUI are an integral part
of the Maplat framework.
Most web frameworks are just that: WEB frameworks, where i could strap on some
communication with workers. They may render fast, beautifull and secure.
For Maplat, it was the other way around: The workers are the core part of the
framework, the web GUI is just a means to provide user access (i could easely
used TK, but that would require local install and therefore more work). It
really wouldn't have mattered if the web pages were dead ugly and long as the
system as a whole did its work.
In the project, i really needed low level control over every aspect. That means
in-depth knowledge of the inner workings of the framework used. So i figured,
what the heck, i'm gonna write my own.
And i did. Had the initial system up and running inside of three weeks. Since
then, i added to it, expanded the functionality and made part of it open
source. More will follow, as i can now spend about 40% of my work time related
to Maplat based projects for at least the next year.
And yes, i take bug reports (and patches, for that matter) VERY seriously -
they may well affect my production systems after all.
Ok, so that was the reason i wrote Maplat and use it in my daily work life.
LG
Rene
--
#!/usr/bin/perl #99BoB (C)2004 cavac:prg count drink vessel place act1 act2
@a...@argv;$c=$a[0]||99;$b=" ".($a[2]||"bottles")." of ".($a[1]||"beer");$w=" ".
($a[3]||"on the wall").",";do{print"$c$b$w\n$c$b,\n".($a[4]||"take one down").
", ".($a[5]||"pass it around").",\n".--$c."$b$w\n\n";}while($c);print"END!\n";
