I really like the idea of providing all of the underlying tools that integrators might need to build sites on top of Habari. Revisions seem to me like a missing component, as did taxonomy, which allowed us to build pluggable features on top, like menus. There is currently no underlying, unifying data structure that could be used for revision or workflow features, so I think this is a good and welcome addition.
As to the greater point of addressing user concerns, I agree. I think it's important to have a useful, competitive tool that also provides a robust framework on which to build. I'd like to discuss other features related to this, specifically WYSIWYG and the recent auto-install ideas from IRC, but under different cover. The only argument I've heard against revisions so far that seems valid is that it may increase default storage requirements for users with many revisions. This may be true. I could be persuaded to consider storing revisions being disabled by default, but the argument against seems more about the code being "lean and mean" than storage requirements. I don't think this feature causes feature/code bloat; rather, I think it's an expected essential capability for baseline blogging today. Owen -- -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev --- You received this message because you are subscribed to the Google Groups "habari-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
