MidCOM 2.5 Roadmap
- Core (torben)
- MidCOM-Template / Site management (tarjei, bergie, torben)
- AIS2 / Aegir 2 (tarjei)
- Component rewrites (torben, bergie, tarjei, ...)
- de.linkm.taviewer (torben)
- de.linkm.newsticker (torben, bergie)
- net.nemein.rss (bergie)
- net.siriux.photos (?)
- Notes on de.linkm.taviewer vs. de.linkm.newsticker
- Packaging (bergie, jval)
This is a MidCOM 2.5 Development Technical Note. Everything written here is subject to change without notice.
This document lists the currently open issues to get 2.6 out of the door. Note that this document only lists major issues, not simple things like "clean up this classes' documentation" etc.
Of course, as much of the bugs reported on Tigris as possible should be fixed before the release.
Core (torben)
No known features missing in the core itself.
Metadata (postponed)
The Metadata system will need a rewrite to the Midgard Metadata system that'll be introduced after 1.7.x. Currently, this is not planned to make it into 2.6.0. The current metadata hiding system is only acceptable with smaller websites.
We should modify MidCOM's default metadata configuration to reflect this:
- Approval and hiding should be disabled by default
- If approval or hiding is disabled, the UIs should not show those functionalities
Datamanager 2 (torben, others?)
DM2 is missing a few widgets (and perhaps types). So far I know of:
- JS Date widget (using type date)
- TinyMCE widget (using either type text in HTML mode or its own type)
- Simple file download widget (using type blobs)
- Download list widget (using type blobs)
MidCOM-Template / Site management (tarjei, bergie, torben)
A new Template must be developed, that does not produce as much overhead as the current solution. The currently suggested way to go is to integrate this a site management component, which creates an "optimized" MidCOM startup sequence within a page/style element, instead of having the startup determined dynamically.
M-T will no longer use shared pages as well. Instead, a common base style should be used to make convenience elements like <(breadcrumb)> available to the site author.
This topic should be covered by its own technical note (or perhaps an mRFC)
AIS2 / Aegir 2 (tarjei)
This new administration systems are mostly complete, but still need fine-tuning and testing.
To make testing easier, I suggest that tarjei writes up some docs how to setup these new components (with additional developer-specific notes how the individual components interact etc.)
Subsystems needed:
ACL Editor (tarjei?)
A simple ACL editor, that has some very limited configurability showing the user preset widget (like a checkbox "allow-this-and-that"). This should be based on Tigert's UI proposal.
A fully fledged expert editor would be good as well.
Object Browser (postponed)
Not mandatory, but it would be good to have a generic object browser which could bind itself to the available MgdSchema types. But this'll need powerful reflection.
Note: Don't we already have this?
Attachments Popup (tarjei?)
Basically a replacement for the Aegir Image Popup but built-in into MidCOM and enabled by default in the WYSIWYG editor.
Component rewrites (torben, bergie, tarjei, ...)
Not all components have been adapted to 2.5 technology yet. Also there have been movements on changing the whole idea of administrations to a pure everything-on-site schema.
While as much as possible of these components should be rewritten, I only see the following components mandatory for the 2.6.0 release:
de.linkm.taviewer (torben)
Needs adaption to the request handler coding strategy, misses on-site administration and DM2 support.
de.linkm.newsticker (torben, bergie)
Full rewrite pending.
net.nemein.rss (bergie)
Will be deprecated in favor of adding cron-based feed subscription (create article from feed) system to newsticker.
net.siriux.photos (?)
Full rewrite pending.
Notes on de.linkm.taviewer vs. de.linkm.newsticker
Tarjei suggested that we merge Taviewer and Newsticker since they are very similar instead providing "configurability" within the component.
This topic is yet undecided.
Packaging (bergie, jval)
The transition to PEAR packaging is mostly done, but lacks integration into the surrounding unix system for post-install scripts and the like.
Static files must still be packaged using Role_Web and we need a MidCOM PEAR channel.