Flower is sufficiently different from other web programming environments that making comparisons and deciding when to choose Flower may not be simple. Here is a small (by no means exhaustive) list of hints about how Flower stacks up.

• Advantage: Ease of Use
• Advantage: Low Complexity Implementation
• Advantage: Ease of Programming
• Untested Advantage: Scaling
• Weakness: Speed
• Caution: Flower is Young

Flower is designed around a few simple metaphors that are familiar to users:

• folders
• documents / applications

The operating system provides but a small set of primitive operations:

• viewing / launching
• editing / saving
• copying
• deleting

Flower presents a model in which "documents are objects" capable of receiving and sending messages. From a user perspective, each document is a kind of "mini-service" than can be invoked, perhaps with parameters.

Flower is remarkably simple compared to systems offering similar functionality. Most other systems (e.g., the various "on Rails" web frameworks) include a large programming language interpreter. Flower's programming language on the other hand is implemented in just a few lines of code, making heavy use the XQuery implementation of the underlying database.

Comparing Web Application Stacks

traditional stack	flower stack
kernel (e.g., Linux)	kernel (e.g., Linux)
web server	web server
RDBM (w/ SQL engine)	XML Database (w/ XQuery Engine)
language interpreter (e.g., Ruby, ~92,000 lines)	flower interpreter (~2,000 lines)
"active object" library (typically large)	none needed

Flower is designed with two economic aims in mind: First to create an improvisational programming environment and drawing upon common skill sets.

"Improvisational programming" means that Flower is well suited for iterative development methods: where requirements development takes place in a feedback loop with application development. Flower achieves this aim by shunning concepts such as compilation and installation: programmers directly edit live instances of the running application at all stages of development.

Flower draws upon common skill sets by keeping low the number of new technologies programmers must learn to begin using flower. Programmers must know:

• XQuery
• XSLT
• the basic concepts of HTTP

To create rich user interfaces, programmers should additionally know:

• CSS
• Javascript

Programmers must learn the Flower Programming language. It has but a few concepts and a single programming construct, and so it can be learned in, perhaps, an hour.

Flower's performance characteristics and capacity limits are mainly governed by the underlying XML database and its XQuery implementation. The current release of Flower uses the open source "DB XML" database and so, in theory, can scale to impressively large data sets and request loads. No experience has yet been gained in this area, though.

On a modest server, with little effort to tune performance, Flower shows request processing times in the range of 70 to 400 ms. That is not an outstanding number compared to many systems however:

• It is fast enough to be economically competitive for many applications, particularly when Flower's clearer advantages are considered.
• Flower performance is likely to improve significantly with only modest amounts of additional work.

Flower is a relatively new project and it has not yet been heavily tested in the field. Moreover, because it is new, many convenience features are lacking, documentation is incomplete, and bugs certainly exist.

Use caution when considering Flower for time-critical projects. Be aware that you may have to help the source "mature" as part of your project. For example, features for user authentication and access protection are not activated in this release.

Copyright © 2007 Thomas Lord Flower source code is licensed under the
Open Software License version 3.0

Copyright © 2007 Thomas Lord This page is licensed under the
Creative Commons Attribution-No Derivative Works 3.0 Unported License .

Flower includes Patent Pending technology.