* Good security record
Enano has a good security record, it had few holes in it during its development period, and these were quickly spotted and plugged up nicely
* Proactive, security minded developer community that is ...
Enano was designed with security in mind, and the developer absolutely believes security is top priority
* Highly responsive, especially to security issues
The Developer will react VERY quickly to any security issues and fix them ASAP
* Flexible enough auth system to attach to FAS
Possible. Enano 1.1.x-hg uses HMAC-SHA1 for password storage, and DiffieHellman + AES192 for password transmission (that is the whole backend). I'm not sure what FAS2 uses for auth system, but it will be likely that the auth system backend in Enano would be entirely rewritten for FAS2 unless FAS2 were to adopt our system. Somehow, I doubt that Fedora would adopt OUR system for authentication :)
Enano's FeedMe plugin provides RSS feeds
* L10n that doesn't break the translator workflow
I have no idea what this means.
* Output for Transifex (PO/POT)
Could be done with a helper script according to the Developer.
* Content workflow (write <=> edit => publish)
No idea what this means.
* Internal version control with rollback capability
Definitely. Due to the wiki capabilities in Enano, all documents have the capability of being rolled back, it supports diffing and revision control
* Content expiration (automatic)
Not sure, but I think this could be done through a plugin
* Multiple roles, e.g. writer, team lead, editor, publisher, managing editor
Defintely. Group support is in Enano and through its ACLs it is possible to set the exact correct permissions for each group to suit its role
* Categorize/tag content for easy base organization
Definite support for tags
* Search that works
Yes. The Search works very well.
* Integrate with FAS
I'm not sure of the integration points for FAS2 for Enano. It was actually because our efforts to get the Fedora Project to use Enano last summer that Enano now has Postgres support, so if FAS2 uses Postgres as a backend, it could be done through that. A method will have to be investigated.
* Be a CMS as a core function, not an add-on
It definitely is a CMS at the core.
* Handle making certain pages or content areas static/non-database driven, such as for scaling during times of heavy resource demand
Can be done with adding a plugin
* Must not lock us in. Data should be portable to another CMS.
Any CMS that supports importing MediaWiki and HTML page data from MySQL/Postgres should be able to import any and all documents from Enano straight from the database.
2009/1/15 Paul W. Frields <stickster gmail com>
On Thu, Jan 15, 2009 at 08:16:31AM -0600, King InuYasha wrote:
> I would like to suggest Enano CMS, which fulfills most of the requirements
> without plugins. It would take some work to get FAS2 integration and stuff
> though. It uses MediaWiki syntax, so it is portable among other CMSes that
> support importing MediaWiki data.
As I understand the post Karsten made earlier, suggestions will be
given credence if they are accompanied by people willing to deploy and
maintain the suggested system. I couldn't tell from your post if
you're saying you're willing to do that, but you may in fact be saying
just that. Could you clarify so the Docs team can understand where to
fit this suggestion into the lineup?