Repositories

Mike asked about the DMS roadmap on that other monster thread, so here is a first draft. Please keep in mind that this is a) definitely not final, b) open to discussion, and c) NOT geared towards functionality. We are in early stages, and still laying down the foundations.

ROADMAP:

1. Cleanup of the Interface subsystem
   This will allow DMS to run inside Moodle, or independently, or whatever, in the future. The current suggested method is to use the inteface/ directory, with subdirectories for each option we want to support. There will be class files in each such directory which the DMS lib.php will load on demand, with respect to the current settings. The _moodleInterface setting is obsolete, as it is too specific and has many drawbacks compared with this scheme. Thus, it will be slowly removed completely from the code.
   
   
2. Construction of a basic DMS API
   After cleaning up the integration stuff, we can expose an API to the outside world. This API will provide ways for programs that use the DMS to call its functions in a clean way. IMHO a good idea would be to write the API as a class hierarchy itself. For example, things like class _DMSMoodleAPI extends _DMSAPI. Then, when you want to use the DMS functions, you can $DMS = DMS::API() which will return an object of the correct class, and you can thereafter do all kinds of fun things like $DMS->create_user(...).
   
   
3. Integration of DMS with the Moodle core
   When the API is in place, we can start tweaking the Moodle core to more fully support the DMS. For example, Moodle itself should be responsible for creating each user's personal folder when the user account is created. For example, $DMS->create_user_folder(...), much like the above. This will allow people to integrate DMS with their sites without being PHP gurus, and fully take advantage of the functionality it has.
   

I 'm not really sure what the next step would be. I can tell you that IMO, when these things are in place the situation will be clearer and decisions on how to proceed taken then probably more to the point. And of course as you see I 'm not keen on rushing to feature-fill the DMS. At this stage, that would result in a hodgepodge of loosely-coupled functions that make up a maintainter's nightmare and someday will force a complete and painful rewrite.

These are pretty basic thoughts, and probably there are hundreds of things that slip my notice right now, so Mike, I 'd be more than happy to see you join the effort and provide ideas, code, or anything else.

Jon