Various technical issues with the current Dragonfly implementation. Where sizes are mentioned, I've tried to ascertain the correct size for what we use, but may be mistaken (it may be we don't use an entire library, or for some other reason I got the size wrong ;)

[edit] Concerns

  1. Size! 'Packed' final.js is 560Kb. We need to be a much lighter download by default; the core needs to be under 100K really. And we haven't really implemented contacts and other important features.
  2. Related to size, speed - login speed now much better that it was, but still room for improvement.
  3. Reliance on a number of external libraries: prototype (80Kb), script.aculo.us (200Kb?!), and MochiKit (120Kb packed). Adds to our size (400Kb in total?), probably making up at least 60% of our size. Many of these libraries do much of the same thing.
  4. Riffing on size still: many people will want to access their mail over https. This limits cacheability. Dragonfly needs to be usable accessing it remotely over a slow connection (100Kbps-1 up?) over https, as a target. Usable doesn't mean "amazing", but live-able.
  5. Concern on the manageability of these dependencies going forward. Will they continue to be developed (Mochi and script.* both seem to be slowing at best), and be compatible (e.g., $ ownership)? Is this sustainable, and will browser compatibility suffer?
  6. Failure modes are silent and often killer. Can we at least detect errors and let the user know something bad has happened?
  7. Mail processing happens on the client side; wasteful. Client side shouldn't need to know about formats / character sets / MIME etc., that should all happen server-side.
  8. Builds a lot of HTML in the code, not wonderful.
  9. Current src/www/ is very dragonfly-oriented, not terribly well separated.

[edit] Future stuff we want

  1. We want to be able to have 3rd party plugins. If the core isn't fast, core + plugins will be horrific.
  2. Some pieces aren't terribly well separated. Makes it difficult to have a consistent plugin architecture. Perhaps the core should be built from default plugins.
  3. Flasher should be buildable out of the same pieces as dragonfly. Maybe flasher is dragonfly, maybe not... ?
  4. We have vague l10n, but not i18n. Particularly not RTL and script languages.
  5. How on earth do we i18n calcmd? Maybe forget about it for now?