Visa källa för Broken/Resource module file API migration

==Current problems==
embedded images are lost during backup & restore which moves the course to a new site. -- Matt Gibson 08:53, 18 May 2009 (UTC)

==Separate contrib modules==
New local files module - contrib - ???? --Eloy Lafuente (stronk7) 16:21, 19 May 2009 (UTC)
mod/resource/type/file/localfile.php is a win32 only hack which is not maintained much these days Petr Škoda (škoďák)

==Extracted from HQ chat, pending to confirm (Y/N)==
I liked the :

* 0 = native 2.0
* 1= flagged as migrated
* 2= pending to migrate
* lastmodified = for still being migrated-on-demand resources

- so, anything with flag > 2 is susceptible to be marked as migrated (1) by any process (manual/automatic or whatever we can implement) and, at the same time, we keep native (0) and flagge (1) d separate, helping to know the orgin of the resource in case we need it later.

- so, on upgrade... I'd mark everything as pending to migrate (2) and then, think on possible ways to perform the lastmodified => 1 conversion (but never to 0. it's reserved for native 2.0)

--[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 09:38, 28 May 2009 (UTC)

==TODO - explain exactly how pluginfile can derive ...==
Here it's a tentative explanation:

The whole path (within legacy course files) will be fully retained when copying files to the resource files area. 

So for example, if we have one resource pointing to: ''"some/dir/with/index.html file"'', the ''"some/dir/with"'' directories will be created (if don't exist) in destination resource file area and then the ''"index.hml"'' file will be copied there (also, if don't exist, obviously).

Then, advancing in the example, if that html includes one link to say: ''"another/different/dir/style.css"'', then the ''"another/different/dir"'' dir will be created (once again, if it doesn't exist) and then the ''"style.css"'' file with be copied there (do you guess when? :-P ).

That way, by retaining the "relative paths" present in legacy course files when copying them to 2.0 resource file areas, the only change will be that old resources being server by "file.php" will be now served by "pluginfile.php", (with different parameters related to course/context/filearea, not important) but 100% equivalent in all their relative links. 

--[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 09:49, 28 May 2009 (UTC)

== Some comments from Tim ==

Brilliant! Excellent detailed spec. Just a few comments:

I added a few comments inline in the main page becuase it seemed easier. Please see main page history.

For the resource_historic table - in the blocks code I used block_instance_old. old is shorter, is it worth being consistent?

mod/page -> Show course blocks options. Martin said that that option could just be removed.

is mod/link a better name than mod/url?

mod/imspackage I have normally seen IMS Content Packaging abbreviated as IMS-CP. Since IMS may come out with other packaging schemes in the future, might it be better to call the module mod/imscp? Or would it be better to have one module to support all the packaging formats that we support? That is, should we go the other way and call it mod/contentpackage? (No, becuase SCORM will still be separate, and anyway, that name is too long.)

--[[User:Tim Hunt|Tim Hunt]] 05:34, 9 June 2009 (UTC)

== Some comments from Ray ==

* References to "Directory". This is terminology that most teachers, trainers etc. are not familiar with. A good time to standardise on the term "folder". MDL-11841

* Perhaps update spec table from "Links to external files in repositories (ie Hive)" to "Links to external files in repositories (e.g. Hive) ".

-- Ray Lawrence 15/6/09

== Jmol Resource: Comment from Geoff ==

I think the Jmol Resource Type should also become a Resource Module (Not Filter, as suggested in the Development Docs)

A separate Jmol filter already exists and does a different (simpler) job to the Resource Type. Latest versions of the Resource Type have a sophisticated configuration interface so that teachers can (relatively) easily build Jmol-based resources with different display options, controls and textual context. This would be (is) cumbersome to do through a Filter.

At their simplest, Jmol resources are Web pages so could be considered a specialised HTML Page Resource Module
At their most complex, Jmol resources are akin to IMS packages. Indeed, I have built Jmol into IMS packages using RELOAD. However, again, this is much more cumbersome than using the Jmol Resource type configuration interface. That said, I do fully appreciate the portability of IMS packages between different systems.

Therefore I suggest the following development sequence (I'll be happy to have a go at this!)

1. Update Jmol filter for Moodle 2.0 (Should be straightforward)
2. Convert the Jmol Resource Type to a Jmol Resource Module /mod/jmol. The current Jmol Resource type was modelled on, amongst others, the HTML and Text Page Resource Types, so the new version could be based on mod/page
3. Consider 'converging' the Jmol Resource Module with the IMS Resource Module mod/imscp. i.e. making the the Jmol Resource Module a specialised form of IMS package. The aim would be to retain the (relatively) simple resource-building interface, but allow import-export with other systems.

Hope I'm on the right lines with this.

----

On further scrutiny, perhaps the Jmol Resource Type is best aligned with Scenario 2 of the general Resource Module mod/resource

Secondary use cases: My additions in '''bold'''.

* simple media file presentation - images, flash, movies, mp3, etc. '''3D molecular coordinate files, .cml, .cif, .mol, .pdb, .xyz etc.'''
* serving of general html files created in external system - web pages, html exported from Word, content packages, etc. '''Web pages exported from built-in Jmol template'''
* presentation of non-standard media files - no full control over embedding, might require proprietary browser plug-ins (quicktime, windows media, real media, adobe shockwave)  '''Java applets such as Jmol, FreeMind etc'''