Hello All!
Just wanted to ask about the status of the "selective" backup and installation process? That is, the ability to backup a certain activity within a course and the ability to install the activity into another course.
WP1
BUMP!! 
Fiiiiiu,
that's "auto-feedback" !
Seriously, just now, it isn't coming, at least from the backup/restore perspective
(talking exclusively about my current list of taks, of course, you know this is OpenSource) 
.
Anyway, perhaps it would be easier to implement it apart from the course-backup format. I've had some thoughts (only thoughts!) about it recently and it sounds better than modifying the course-backup-restore "monster". If my "thoughts" evolve in something more specific, I'll tell it, sure!
Ciao
that's "auto-feedback" !
Seriously, just now, it isn't coming, at least from the backup/restore perspective
Anyway, perhaps it would be easier to implement it apart from the course-backup format. I've had some thoughts (only thoughts!) about it recently and it sounds better than modifying the course-backup-restore "monster". If my "thoughts" evolve in something more specific, I'll tell it, sure!
Ciao
Hi Eloy!
Thanks for the "get back".
WP1
In reply to Eloy Lafuente (stronk7)
Re: When --> "Selective" backup & installation
by Gustav W Delius -
I don't think this backup and restore for individual activities should be coded separately from the course-backup-restore monster. As you know it is difficult enought to just maintain a single code base. Rather the monster should be tamed by modularizing it. It seems to me that this can be done incrementally, module by module. That is the only way it will ever happen.
In reply to Gustav W Delius
Re: When --> "Selective" backup & installation
Hi,
I agree completely about your opinion, Gustav. Maintaining two separated threads of coding is really difficult, more if such threads affect core features like the backup/restore.
But, thinking in future applications for individual activities (not only backup and restore in its current approach, but sharing them using a lot of alternative ways like web-services
, p2p 
, repositories 
...) the XML format used should evolve in a better format to add support to MUSTs like metadata 
, DTD validation... XLST transformation to other formats...
And all this will break backup/restore as it's currently implemented and will force us to maintain two lines of code, exactly like the quiz restore is being supported now.
So, why not to start by creating and designing all those new XML stuff without the constraints of current backup code, leaving it to follow its own development cycle and, once all the new XML architecture is created use it to build the new, improved, 2.0 version of backup and restore.
With this, old courses could be restored without problems, because such line of development has continued active and independent. And starting in versión 2.x of Moodle we could start to create 2.0 backup files (with its own structure and code).
I must remark that all these are absolutely preliminary ideas and I'm pretty sure that every alternative has advantages and handicaps, but I think we shouldn't avoid the "separate completely" alternative yet.
Perhaps, once defined the objectives of the whole thing, we could decide the best road map to fulfil it, but not before (pop*, of course).
Ciao
*pop: personal opinion
I agree completely about your opinion, Gustav. Maintaining two separated threads of coding is really difficult, more if such threads affect core features like the backup/restore.
But, thinking in future applications for individual activities (not only backup and restore in its current approach, but sharing them using a lot of alternative ways like web-services
And all this will break backup/restore as it's currently implemented and will force us to maintain two lines of code, exactly like the quiz restore is being supported now.
So, why not to start by creating and designing all those new XML stuff without the constraints of current backup code, leaving it to follow its own development cycle and, once all the new XML architecture is created use it to build the new, improved, 2.0 version of backup and restore.
With this, old courses could be restored without problems, because such line of development has continued active and independent. And starting in versión 2.x of Moodle we could start to create 2.0 backup files (with its own structure and code).
I must remark that all these are absolutely preliminary ideas and I'm pretty sure that every alternative has advantages and handicaps, but I think we shouldn't avoid the "separate completely" alternative yet.
Perhaps, once defined the objectives of the whole thing, we could decide the best road map to fulfil it, but not before (pop*, of course).
Ciao
*pop: personal opinion