Proposal:Penelope
From MovableType
Contents |
Penelope
This proposal was initially submitted with the title MTOS Project Roadmap. To avoid confusion with the current and official MTOS development track this proposal has been code named Penelope and resubmitted here.
Purpose
The purpose of this proposed project is to refactor the core MT application to both support and contribute the open source efforts abroad. This work will result in a next generation framework (engine) and supporting components for building Movable Type and other MT-style applications.
Summary
The purpose of this document is devise a direction for MTOS as an open source project at a high "20,000 foot" level. It is not meant to determine or exclude a product roadmap or other small incremental functionality or patches that will inevitably need to be made in the future. It is meant to devise how to evolve the MTOS code that was developed under a close commercial license and integrate it with the broader open source ecosystem.
Steps include breaking out piece of existing functionality into subprojects that can be submitted to CPAN, refactoring and replacing redundant functionality with existing CPAN libraries and finally a ground up build of the core MTOS engine using this integrated and modularized approach.
These milestones are mostly independent of new version releases other then what this document calls "MT 5" in Milestone 3. So if you are wondering when and if feature X will be implemented or bug/issue Y will be addressed or when version Z will be released this is NOT the document for you!
Requirements
MTOS needs to be reorganized and expanded to be a primary appication by fed by a collection of discrete sub projects that can be used seperately from the primary application if needed.
This is similar to the Mozilla project where the browser application is the primary focus, but numerous other projects have developed and are run in loose coordination with its primary goals.
The intended benefit:
- New, improved and refactored functionality can be developed and tested seperately of the main MTOS branch.
- Encourages better overall modularity and OO design.
- Broadens the utility and reach of the MTOS efforts (read: makes it more "CPAN-able") and builds the knowledge of MTOS and interest in contributing.
NOTE: This prerequisite would only entail accepting and organizing for subprojects to exist, but NOT identify all of them. This would come out of the work of Milestones 1 & 2.
Effect on the platform/existing features/code
This project would oversee significant code refactoring of the MTOS system in order to fully realize its status as a part of the larger open source software ecosystem. While breaking backwards compatibility would be less then ideal, some breaks may be necessary for the forward progress of the platform. For instance, some MT4 plugins may break without revision.
What is crucial is that all breaks are documented and well publicized before the an official release based on Milestone 3 is made. It will behoove the community to start introducing a migration to the new interface as soon as possible through alternate interfaces and aliases in MT4.x released.
This work should NOT remove any functionality that exists in the existing version of MT except for that which has been labeled deprecated as of MT 4.0.
If done correctly MTOS will be more familiar to developers outside the immediate MT community and thereby lowering the barrier to entry and leveraging the existing knowledge, documentation and books that come from these external efforts.
Effect on existing, upgrading users
This effort itself does not necessarily require any user facing features to change. Upgrading procedures *may* be effected in ways that require special handling though.
Effect on future new users
The effect of these changes is to leverage the existing work and experience of other open source projects to lower the barrier to entry for developers of various types and so this community can focus on more on product features that make MT unique. The belief is that by using familiar established libraries and tools experienced developers will be more likely to use and contribute to the community.
Project Plan
Milestone 1: Identify & document CPAN packages that could replace existing MTOS code
This milestone would involve looking to effectively leverage existing resources for use in MTOS rather then continuing to support and maintain its own version of the same general functionality.
In a blog post Tim Appnel said, "What does MT gain from having its own application framework? (I can ask this same question of JavaScript frameworks and some other things in MT.) How will that differentiate MT from other tools? How does it improve the user experience or get more people using the tool? It doesn’t. Could the engineering resources of Six Apart and this community be put to use on other things where the questions are true or an alternate does not exist? I’m pretty sure the answer to that is yes. So if there is a passionate community of developers that have put a lot of time, effort and field testing in to a library that provides essentially that same functionality, I’m all for it so we can work on the things that really need it."
Mark Stosberg proposed a similar view on mtos-dev saying "you can outsource the infrastructure parts of the application to well documented, well tested, CPAN modules supported by active maintainers, and focus on the parts that are really value-added for customers." He stated the inverse of this as "continuing to support your customized full-stack infrastructure, continuing to add tests and documentation up and down the stack to make it more accessible to developers, while mostly duplicating solutions already on CPAN through a monolithic API."
This milestone would entail identify packages and any short comings, potentially working with those maintainers to submit patches, and documenting how these packages would be utilized by MTOS.
Special consideration and care will need to be given to avoid requiring any packages that need, directly or through its prerequisites, any specific operating systems, binaries or compilation of code. Also packages with excessive dependencies should be avoided.
See Proposal:Foundry#Required_Module_Mapping for a list mapping CPAN modules to MT functionality.
Milestone 2: Make unique subsytems of MTOS "CPAN-able."
This milestone would entail identifying what parts of MTOS are in some way unique to MT and does not exist in CPAN and then breaking them out in to libraries/packages that can standalone (have utility outside of the MT application). The intention is for these libraries to be submitted to CPAN for general use in addition to being used by MTOS itself. Each of these libraries would become subprojects under MTOS.
Potential examples would be:
- Data::ObjectDriver as an MTOS project
- Typist (Base MT Template Engine. See aborted Typist effort in CPAN.)
- YAML::Registry system
- Plugin system (using YAML::Registry and Module::Pluggable)
- Pluggable File Manager system
- Prioritized callback system (using Class::Trigger)
- Task Manager and JobQueue daemon
- Session Manager
- SQL update engine
- Authentication driver and management
- Atom API endpoint/server
NOTE: This is a list of potential candidates and not a final or official list.
Milestone 3: Foundry & Required MTOS Subsystems
Proposal:Foundry is the next generation framework written in Perl for building MT and MT-style applications.
This rewrite of the core framework will endeavor to leverage as much existing and established open source Perl code (via the CPAN repository) and modularize parts in the MTOS code base where such a library does not already exist.
Is it the aspiration of the Foundry effort to be used by the the MTOS trunk for "Movable Type 5" though this is *not* an official goal or milestone.
In addition to Foundry, a number of other subsystem projects will be devised that encapsulate specific and essential addon functionality by integrating the modules identified and released in Milestones 1 & 2 for MTOS' use. Such subsystems include a YAML registry manager, plugin system and so on.
Milestone 4: "Movable Type 5"
Pulling together all of the work of the previous milestones in to the MTOS core. This also would include:
- Removal of MT3 deprecated functionality
- Fully realize the modular architecture first proposed by MT4. (URL?)
- Avoid breaks whenever possible including...
- Create optional compatibility layer for MT4 breaks if possible and...
- Clearly documenting those breaks and why they are deemed necessary.
Missing: Other Refactoring
Clean-up of code not impacted by Milestones 1 & 2 directly, but refactoring would be a good idea. For instance, application templates use HTML::Template workflow though they are now rendered by MT or splitting up MT::Util or the MT::Template::ContextHandlers in to smaller logical pieces.
Implementation Notes
This undertaking will be developed separately from and in parallel to future MT4 releases. This work cannot be rushed and should remain mostly independent of the MT4 product roadmap.
Resources
Project Team
Below is a list of community members participating in the project. All users are linked to their wiki user page and project leaders are marked with an asterisk.
If you are interested in participating but still not sure, add yourself to the bottom of the list. You can italicize your name if you are interested but undecided.