View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 2 | Composr | core | public | 2010-04-05 21:28 | 2012-09-08 11:55 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | closed | Resolution | won't fix | ||
| Summary | 2: Revision history | ||||
| Description | Stop using 'auto_increment' in Composr, and switch to random ID numbers instead. This will allow content to be synchronised between sites without ID-conflicts. Replace the PHP code in the actualiser functions with XML code that specifies the new content, as well as actions to perform (except the log_it call). Each actualiser function has an explicitly defined 'op-path' which is consistent with the function name. For example the 'delete_gallery' function would be stored as 'gallery/delete' in the database, so that the REST API can be structured. The name ('gallery' in this example) has also to be consistent with the content_meta_aware hook for the content-type. In the actualiser function log_it calls pass the op-path and XML code in the log_it call, effectively extending the action log to store full changeset data formally against the details of which content_meta_aware hook that handles it. log_it must be smart enough to take the XML data of an edit and only actually stores fields that have changed (by comparing with the current version of the record being edited). The content_meta_aware hooks will absorb the award hooks and also a lot of the content-type definitions that currently reside in modules, and also database table relationship data currently defined in one of our addons. The hooks will inherit from a new base class that provides utility functions upon the hook data, such as producing and executing the aforementioned XML (this will be taken from Composr's existing admin_xml_storage system). This allows us to use object inheritance to override the automated behaviours as a future-proofing compatibility layer, and also provides growth possibilities for also handling imports using the hooks. Keep Composr's admin_xml_storage module as a manual console that developers can use to inject XML. However it should be demoted from any promotion as a first-class tool for content-syndication. The admin_actionlog module will become the gateway for working with changeset data. It will provide functionality to 'revert' and 'push-to-live' and 'view-raw-XML' any action, subject to the limitations below. This can be done by checking off items on bulk (with a 'check all' option), or by doing it on individual action. Limitations: 1) 'push-to-live' is only available if a companion server(s) has been configured for the site (will need the servers master password entering in as a config option value). 2) For compatibility with old Composr installations, the 'revert' option should not be made available for a 'delete' action if there is no corresponding 'add' record for that content ID. 3) The features are only available on revisions that have attached changeset data. The intention is that Composr 8 will provide this for almost all log_it calls, but old revisions will of course not have the data needed. Some revisions cannot be reverted, such as sent emails, and thus won't have a changeset. Implementation notes: 1) Reverting works as a delete then a reapplication of every changeset up to the deletion revision. 2) If pushing, you must push every prior change to the same content that has not yet been pushed, in order for consistency to be maintained. The system will automatically handle this by auto-including the relevant items in the push. 3) Similar to the above, If reverting, you must revert every subsequent change to the same content that has been pushed. Failure-tolerance scenarios: 1) The server may respond with an error code 404, indicating an action is being performed on something that does not exist. In this case the push code will automatically re-push, with a full history of revisions for the item starting with it's original add operation. 2) Records may refer to other records that may not exist on the companion server (e.g. users). To handle this Composr will use data defined under content_meta_aware hooks, as well as database schema data Composr stores (in the db_meta table), to ascertain how to map to something that does exist. Messages will be returned by the server when this happens. The admin_actionlog module must get a better filtering interface, so that you can easily just see un-pushed actions or filter to a specific content-type or content-ID. There should be an additional 'purge' button for any deletion revision, that purges record of that content ever existing via erasure of all it's revisions. The push-to-live feature will work via calling up via a REST web service, which is based on the aforementioned op-paths and the XML data. It is secured via the master password (there is no fine-grained access control devised for it at this time). The 'revision history' features used by forum posts, and CEDI will all be replaced with this new standard system. The buttons/links and interfaces that they have to access the data will remain, but the interface behind them will work by pulling out data from the Action Log. Similarly, Comcode Page, CSS, and Template, editing will have their own 'revision history' functionality replaced by a filtered and embedded version of the Admin Log screen. In fact, all 'edit' screens will get 'revision history' functionality like this. Integrations with other aspects of Composr: ------------------------------------------- Composr's workflow addon will become a core Composr feature, available for many content types. A new button will be put on it after a workflow is completed, to 'push-to-live' the involved data. The staff checklist on the Admin Zone front page will include a new item that displays how many items have not been pushed-to-live. Commandr's file system will be extended with a new 'var' filesystem hook to be able to navigate XML records for any defined meta_content_aware content type (directories based on the content-type's categories). This functionality will be a precursor to webdav support (where we will extend webdav into the same filesystem, but also provide import/export changes to common interchange-filetypes). Terminology: ----------- The 'Action-Log' shows a number of 'Revisions'. Revisions may include a 'Changeset' (written in 'XML') and an associated with an 'Operation Path' describing formally the action. Revisions may be 'Pushed-to-live' or 'Reverted'. 'Pushing-to-live' works via a 'REST web service'. 'Pushing-to-live' can also be initiated easily at the end of a 'Workflow'. Additional use cases: -------------------- By implementing an auto-push option we can easily set up low-maintenance database replication between sites for purposes of scalability. Because changes may still be made on a 'live' site independently of the 'staging' site, you can also set up a number of different sites, then push the same content to them, allowing a white-labelled site-content-network to function. | ||||
| Tags | Risk: Database change , Risk: Major rearchitecting , Skills: Lead programming | ||||
| Attach Tags | |||||
| Attached Files | |||||
| Time estimation (hours) | 100 | ||||
| Sponsorship open | |||||
|
|
More nice-to -aves.. scheduled publishing of push Ideally, allow the REST API to work with normal permissions |
|
|
If workflow is implemented then we need to update our listing on cmsmatrix to reflect this. Ditto once we are happy with our extendable 'meta data' support. |
|
|
I am verging on throwing away the core XML syndication idea, and changing it to the virtual filesystem in 218. This way we are representing content within interchange formats. These can be hand-edited, directly managed in normal tools (e.g. video editors, photoshop), managed from git (which is a nicer workflow than juggling with complex structured XML) and interfaced with by other systems that don't want to be Composr-specific. I like the idea of separating out the content into two: - Core content (documents, videos, etc) - Social aspects (view counts, comments, etc) You have little or no desire to syndicate the social aspects (except using replication on redundant networks) - in fact you probably don't want it. The social stuff does not fit with the interchange formats either. However, the core content can syndicate great with webdav and git, using interchange formats. |
|
|
New revision control strategy will focus around WebDav, Commandr, and Git. Content syndication can be done with MySQL replication. http://dev.mysql.com/doc/refman/5.0/en/replication-options-master.html |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-08 00:14 | Chris Graham | Tag Renamed | Major rearchitecting => Risk: Major rearchitecting |
| 2016-06-08 00:15 | Chris Graham | Tag Renamed | Database change => Risk: Database change |
