Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Backup 2.0 - Converters review 2011-04: Difference between revisions

From MoodleDocs
No edit summary
Line 23: Line 23:
=== Feedback from Mark regarding review ===
=== Feedback from Mark regarding review ===


test
==== Related to integration with restore_controller & general behavior ====
 
* R0401: I see what you are trying to get at here, but seems like over architecting IMO.  For example, you have something that goes from FOO > BAR > MOODLE2 (CONVERTPATH1) and then you have something that goes to FOO > MOODLE2 (CONVERTPATH2) both installed, then your proposal would be necessary.  Though, why would you have both installed?  CONVERTPATH2 would replace CONVERTPATH1 making CONVERTPATH1 obsolete and never used anyways.  Anyways, I'd say let's hold this off as a fun project after everything else is done.
* R0402: I don't see much of an advantage here as by moving to static you then loose access to all of your instance variables and methods.  Cost of creating a new instance shouldn't be that terrible.  If this is required, fine, let's do it.
** As for checking the environment, I think that can be done in can_convert right?  Part of figuring out if it can handle the conversion.
* R0403-5: These are fine.  We should probably make our own converter_exceptions, what do you think?
 
==== Related to the converters/moodle1 infrastructure ====
 
* R0408: There is execute_after_convert but really, that's called after the XML has been processed.  Execution flow is kind of weird due to the processor.  We could add another stage of processing, though I do think execution flow will greatly improve once start/end callbacks are being used.
* R0410: I'm not sure what this is.
* Rest are fine.
 
 
==== Related to coding in general ====
 
* Sounds fine.

Revision as of 19:53, 28 April 2011

Please, for discussing any of the points in the page, do it in the corresponding MDL-xxx issue in the Tracker. TIA! --Eloy Lafuente (stronk7) 22:45, 26 April 2011 (WST)

Ongoing discussion Eloy & Mark (20110428)

Three (3) targets are planned, no action on next target will be performed before completing the previous one:

  • The "basic" (1st): Be able to restore everything but user-related information.
  • The "desirable" (2nd): Be able to restore activity user-related information.
  • The "complete" (3rd): Rest of information.

From the review, points 01-19 must be analyzed, discussed and implemented, specially the ones detected as blockers for the consecution of the targets above. The ones not being considered blockers can be left for later, once the "basic" (1st) target has been fulfilled. The review page will show which ones are considered blockers and where (MDL-xxxx) their implementation is going to happen.


Immediate plan, something like:

  • you take a look to those points and add any objection / comment / missing point in the last section of the page.
  • I also take a look to the thing and start implementing some stuff, like the start/end dispatchers and some tests to have them under control.
  • Next day, availability of parties determined, we share thoughts.
  • Next-next day, we start "doing" things :-)

Feedback from Mark regarding review

Related to integration with restore_controller & general behavior

  • R0401: I see what you are trying to get at here, but seems like over architecting IMO. For example, you have something that goes from FOO > BAR > MOODLE2 (CONVERTPATH1) and then you have something that goes to FOO > MOODLE2 (CONVERTPATH2) both installed, then your proposal would be necessary. Though, why would you have both installed? CONVERTPATH2 would replace CONVERTPATH1 making CONVERTPATH1 obsolete and never used anyways. Anyways, I'd say let's hold this off as a fun project after everything else is done.
  • R0402: I don't see much of an advantage here as by moving to static you then loose access to all of your instance variables and methods. Cost of creating a new instance shouldn't be that terrible. If this is required, fine, let's do it.
    • As for checking the environment, I think that can be done in can_convert right? Part of figuring out if it can handle the conversion.
  • R0403-5: These are fine. We should probably make our own converter_exceptions, what do you think?

Related to the converters/moodle1 infrastructure

  • R0408: There is execute_after_convert but really, that's called after the XML has been processed. Execution flow is kind of weird due to the processor. We could add another stage of processing, though I do think execution flow will greatly improve once start/end callbacks are being used.
  • R0410: I'm not sure what this is.
  • Rest are fine.


Related to coding in general

  • Sounds fine.