We've completed development for the Common Cartridge Import/Export upgrade to Moodle 2, and would like to share the code with you for (hopefully!) eventual inclusion into the core product. The implementation converts the available cartridges hosted by IMS and we anticipate it will be certified as IMS CC 1.0 and 1.1 compliant. We have the code hosted on github and opened a related tracker ticket at MDL-29956. The architecture should be sound and consistent with the Mark and Darko's original design with help from Eloy. Fortunately, the design allowed us to leverage much of the original code from 1.9. All in all, I think you will find the CC backup/restore routines to be very clean and non-invasive to the existing code.

I would like to point out that the code is still going through QA cycles, so we anticipate there will be some minor changes made as a result. The documentation we have around CC also needs to be updated based on the development and QA effort, but I would be happy to share the Product Specs, the Developer docs or both in their current status if you think that would be helpful. In addition, I know that in some older conversations around CC for 2.X it was suggested that it be released as an experimental feature - we don't have the option in the current patch, but we could add it very easily as there are very few modifications made to core files. So some polish may still be needed, but it's nothing that couldn't be handled in a STABLE sprint and I know that we are all eager to get the CC code included into the next version of Moodle.

Martin Dougiamas
added a comment - 04/Nov/11 12:02 PM I really hope this can be integrated for 2.2.
I'm including part of an email from Kris Stokking at Moodlerooms:
We've completed development for the Common Cartridge Import/Export upgrade to Moodle 2, and would like to share the code with you for (hopefully!) eventual inclusion into the core product. The implementation converts the available cartridges hosted by IMS and we anticipate it will be certified as IMS CC 1.0 and 1.1 compliant. We have the code hosted on github and opened a related tracker ticket at MDL-29956 . The architecture should be sound and consistent with the Mark and Darko's original design with help from Eloy. Fortunately, the design allowed us to leverage much of the original code from 1.9. All in all, I think you will find the CC backup/restore routines to be very clean and non-invasive to the existing code.
I would like to point out that the code is still going through QA cycles, so we anticipate there will be some minor changes made as a result. The documentation we have around CC also needs to be updated based on the development and QA effort, but I would be happy to share the Product Specs, the Developer docs or both in their current status if you think that would be helpful. In addition, I know that in some older conversations around CC for 2.X it was suggested that it be released as an experimental feature - we don't have the option in the current patch, but we could add it very easily as there are very few modifications made to core files. So some polish may still be needed, but it's nothing that couldn't be handled in a STABLE sprint and I know that we are all eager to get the CC code included into the next version of Moodle.

I've been reviewing all this along the last days, and it's great code but have found some problems that, after a lot of thinking and sharing it with Martin have leaded to the next conclusions:

1) CC-Import: It's ok to send it upstream. It uses current support for backup converters in a proved way (1.9 => 2.x is using that already), integrates perfectly in the restore process and uses a lot of the logic that was present in the 1.9 importer. Also, it's somehow a bug-fix as far as restitutes one functionality we lost in 2.x.

2) CC-Export: This cannot be integrated right now. It is new code, leading to one integration with the backup process that needs to be planned/discussed/agreed a bit more. This is a (cool) new feature, but it's not ready for the masses and, right now, roughly 2-3 weeks to release, is not the time to fix it.

So, the immediate plan to get as much as possible of this landing is:

1) Create one new $CFG->experimentalccexport setting, without UI, only available manually @ config.php that will "enable" cc-export, so backup won't get any change by default. This is the optimal solution, so all the code will land already in core and we'll be able to work there after release and will enable devs and other sites to use it as experimental feature if wanted.

2) If I cannot isolate and get 1) done, I'll fallback to a more radical solution, deleting all the cc-export code interfering with "normal" backup. Then, after release, we can re-introduce it safely in future master branch (that will be 2.3 in 6 months).

And that's the plan for NOW. I'm working on 1) above right now aiming to release 2.2beta in hours.

Once again, I want to insist that I've liked the ideas/code I've seen, absolutely. Great job, guys!

Ciao, Eloy

PS: Side note, we would need some MDQLA tests covering CC-Import, do you've something about that (packages, tests...) we can incorporate to our MDLQA iterations?

PS2: While trying cc-import I detected that some resources were not imported properly, leading to "file not found" errors, it was using the well-known "OrganicChemistry.zip" 1.0 package. (seem to be file-related problems both in file resources and question images)

Eloy Lafuente (stronk7)
added a comment - 14/Nov/11 8:24 PM - edited Hi all,
I've been reviewing all this along the last days, and it's great code but have found some problems that, after a lot of thinking and sharing it with Martin have leaded to the next conclusions:
1) CC-Import: It's ok to send it upstream. It uses current support for backup converters in a proved way (1.9 => 2.x is using that already), integrates perfectly in the restore process and uses a lot of the logic that was present in the 1.9 importer. Also, it's somehow a bug-fix as far as restitutes one functionality we lost in 2.x.
2) CC-Export: This cannot be integrated right now. It is new code, leading to one integration with the backup process that needs to be planned/discussed/agreed a bit more. This is a (cool) new feature, but it's not ready for the masses and, right now, roughly 2-3 weeks to release, is not the time to fix it.
So, the immediate plan to get as much as possible of this landing is:
1) Create one new $CFG->experimentalccexport setting, without UI, only available manually @ config.php that will "enable" cc-export, so backup won't get any change by default. This is the optimal solution, so all the code will land already in core and we'll be able to work there after release and will enable devs and other sites to use it as experimental feature if wanted.
2) If I cannot isolate and get 1) done, I'll fallback to a more radical solution, deleting all the cc-export code interfering with "normal" backup. Then, after release, we can re-introduce it safely in future master branch (that will be 2.3 in 6 months).
And that's the plan for NOW. I'm working on 1) above right now aiming to release 2.2beta in hours.
Once again, I want to insist that I've liked the ideas/code I've seen, absolutely. Great job, guys!
Ciao, Eloy
PS: Side note, we would need some MDQLA tests covering CC-Import, do you've something about that (packages, tests...) we can incorporate to our MDLQA iterations?
PS2: While trying cc-import I detected that some resources were not imported properly, leading to "file not found" errors, it was using the well-known "OrganicChemistry.zip" 1.0 package. (seem to be file-related problems both in file resources and question images)

Kris Stokking
added a comment - 15/Nov/11 12:04 AM Eloy, I think that is a great approach. Thank you very much for your efforts, and if there's anything we can do to assist in #1, please let us know.
Regarding the MDLQA tests, we are putting the CC code through IMS validation testing this week and can share the full testing plan with you by the end of the week. Will that be enough time for QA?
Regarding the OrganicChemistry.zip, we'd be happy to include that in our testing - can you share a URL?

Uhm, I think it is (was) one of the sample cartridges available @ the IMS CC/LTI Alliance site (for demoing IMS-CC 1.0?) Just have checked it now and the examples page seems to be under re-construction.

In case you have not it, I think it's oki if I send you it privately (after all both us are members of such alliance).

Eloy Lafuente (stronk7)
added a comment - 15/Nov/11 12:30 AM Uhm, I think it is (was) one of the sample cartridges available @ the IMS CC/LTI Alliance site (for demoing IMS-CC 1.0?) Just have checked it now and the examples page seems to be under re-construction.
In case you have not it, I think it's oki if I send you it privately (after all both us are members of such alliance).
Ciao

Eloy Lafuente (stronk7)
added a comment - 15/Nov/11 4:52 AM Doing a few tests before considering this integrated and test passed. MDLQA & conformance tests should be enough (although don't forget the problems detected with the package above).
Then, I'm going to create one new backup: ims-cc component, adding to Darko as leader (if that is ok) in order to use it to have all the ims-cc issues under control.
Finally, one new issue will be created about to discuss and agree the backup exporters infrastructure support (that IMS-CC export should be using).
That's all... coming back in some minutes... ciao

Eloy Lafuente (stronk7)
added a comment - 15/Nov/11 6:57 AM I've added one more commit fixing some whitespace (tabs) and basic-tested it, both import and export and with the setting above enabled and disabled. Everything seems to be going ok.
Also, I've created the "Backup: IMS-CC" component with Darko as leader.
Finally, MDL-30265 is the issue where all the post-2.2-release work should happen.
So, marking this as integrated and tested, yay!
Ciao
PS: Please, report any incidence with the IMS test suite and also anything detected by testing, reviewing as new issues here in the Tracker.