Planned subsystems
1. Load balancing and distributedness
As server class machines are outrageously expensive, it seems a good idea to architect the software we write to be inherently distributed. It would be nice to do it as soon as we have resources for it, since there is a 'point of no return', and most failed enterprises list this as a major cause of their failure.
Also, as we would like to offer services world-wide, it seems to be a very important to have servers in several continents (to minimize the latency of page display). This requires a good architectural design of our software. First the architecture should be drawn and described, then the development effort estimated...
2. Integration of the distributed storage solution of LJ
LiveJournal guys implemented a cool distributed storage system for picture storage. It is not a POSIX filesystem, as it doesn't allow file modification. However, with this extra condition a very fast distributed storage was implementable (and has a free license).
3. Avalanche tagging
- Rule executor subsystem that is triggered when a new tag appears
- Tag rule creation ui in GWT account page
4. Basic portal interface elements
a) Article display page with frontpage engine
A regular journal/blog page usually contains sidebars with elements. blogger for example lets the user to select which sidebar elements (archives, calendar, ads, ...) to show in the blog. This functionality is important --- and there is no reason to implement it again, since the frontpage engine fits pretty well. Every gadget can be some special boxrenderer, and that's all.
b) Backup while editing
- Browsers crash.
- Not everybody uses mozex+emacs to fill in textareas :).
From these two, one can easily deduce that the nowadays popular functionality of background regular autobackup of currently typed text in textareas is an important thing to have, and we should have it too...
c) GUI for frontpage and journal display page design
We should create a gui that allows the user to create his own journal frontpage and article display page templates.
This GUI should exploit the planned structure of frontpage templates: hboxes, vboxes and content boxes. The GUI should facilitate the creation of self-sizing pages (instead of the net-wide dominating fixed width pages...).
The GUI should let the users to create and reuse boxrenderers (being able to use each others as well).
d) Sidebar gadgets
One should sit down and think about what sort of sidebar gadgets should we implement for MM2-4. We should create some wiki page for them. These gadgets should be available via the journal design gui, just like user created boxrenderers are.
