Here's how it works:

1. With sharing turned on, links to resources/activities in a parent course appear in the corresponding topics of all child courses
2. Parent resources are identified by a course (projector screen) icon
3. Topic summaries are inherited if they have not been set in the child course
4. Clicking a parent resource in a child course opens the parents resource.
5. Sharing can be turned off in the parent or in individual child courses

Advantages of this approach are:

1. Students need not navigate to a parent course to access its resources
2. Any activity (not just uploaded files etc) can be shared seamlessly between courses
3. eliminates duplication of files/activities
4. Allows large subjects (general science has aprox. 8 identical classes running concurrently) to easily share core curriculum material.
5. All participants of child courses are automatically enrolled in the parent so no extra admin is required

There are of course a few limitations/downsides to this approach:

1. Interactive activities belong to the parent and so don't differentiate between the participants of child courses (eg. assignment, quiz). For individual class records, the activities need to be duplicated in the child course.
2. Some pre-planning must be done to ensure all child courses topics match the parents.
3. Parent resourses are not included in child backups.
4. The breadcrumb trail when viewing shared resources (from a child course) provides a link back to the parent course, not the child which can be confusing

I'm not sure yet if Catalyst have sumbitted these modifications to Moodle CVS for everyone to play with, but I'm keen to see what the moodleverse has to say about them.

This can be done now of course (assuming the files are open to the world), and in the resource module you simply specify the URL to the file.

Two problems with it right now are:

• the interface is clunky and there is no easy browsing GUI
• it's not supported all over Moodle

These are the problems that the new Repository API seeks to address: http://docs.moodle.org/en/Repository_API

I do not "entirely" understand why this is not simple to resolve quickly. It seems to me that one level of indirection is needed. The location of the item/resource/files does not need to be known by the user needing access to it. Can't a shared resource be given a "type ID" identifying it as a "type" of item/resource/file that can be shared. The user wanting access selects the resource from a list (extracted from a database that maintains a simple list of shared resource file locations and access permissions). The user only needs to keep a link to the resource(each resource should be given a resource ID). The issue of permissions (to access the resource) is surely one that can resolved without too much difficulty - the uploader of the resource to be shared will need to select options to specify who or what type of user can or can not have access to the resource.

How does PHP handle data in complex data structures? e.g. lists, singly/doubly linked, queues, trees, maps, etc. Languages such as C/C++ provide pointers and references that make data handling easy. If PHP has limitations in this area, is there a library that can provide the implementation of these data structures instead?

It seems many people want nothing more complex than a) "front page>site files" but restricted to users that are allowed b) the ability to see such files when writing a course so that they can add them like they can add other files.

If I walked in to a library, without a library card (guest access) I could see quite a lot. If I wanted to look at a particular library collection (a course) I would have to sign up (enrol) for that course. And if I were one of the collection curators (teachers) I would have access to objects in the collection and to use them in my classes.

I am therefore not sure why we particularly need "metacourses". All we need is the capability to duplicate the Site Files but to add a role to it that would restrict permissions to access it.

This could be nested, for example:
Library
> Geograpy stuff
>> map room
>> social geography
> Biology stuff
>> taxonomy
>> cell function
etc.

Provided, as a teacher, I can add stuff to, say "map room" and if I were making a new class I could see files to allow me to "select" those files to use. I am happy. If I don't want the biology students to see my maps (for some reason), no problem, I just set permissions for geography students to allow and biology students to not allow.

In the same way the "site files" could now be protected from "everyone who is not logged on" by saying "guest" has no permission. And "site files" could become a general library.

Of course, I use the word "file" here, but it need not stop me having something like my site-wide glossary available everywhere rather than having one glossary per course. All you need to do is change it from "site files" to something like "site resources". The "site resources" then becomes a real library of things which you can use wherever you want them and can be backed up separately, as a course, like all other courses. Now you no-longer have to backup links because you backup the site resources once.

Or have I missed the point?

I put all the resources in a mother course. Assign groups to the course and then allow students groups acess to the mother course as a group members.

I use a "redirect course" (or doorway course, a very simple course format that redirectrs to another course) so that students are given the impression of being a members of a different course.

The problem with this method is that activities and resources are common to all groups and can not be hidden, meaning that individual course instructors can not create their own activities and content.

Since the method of sharing content among different cohorts as groups is in place, this latter problem could be solved if groups were made even more mutually "invisible," with not only content, but also activities selectably invisible.

Tim

There are some interesting ideas in this tracker issue but I'm pretty sure that if these were to be implemented in core that they would not go far enough for many users seeking to "properly" share files and that we would be in a position of greater compromise and dissatisfaction. Although the current course-centric position is not ideal in many situations at least it's clearly defined.

Ray - when you say "document management" what does that really mean? For me "document management" means systems where a whole collection of documents need to be controlled, each one having a document ID and a version number and a date of issue and appropriate signatures etc This might also involve a version tracking system so that previous versions can me revisited. I don't understand how this fits in with the problem I described. When you say "dedicated repositories" - Moodle already has a database - I envisage nothing more complicated being needed than that to address the problem I am concerned about.

In simple terms, for example, lets say I have a base document - a government document that I often want to look at for planning, or a useful resource such as a list of words with examples of the various phonemes, consonant digraphs, etc used when teaching (or planning) children how to decode words when reading. I need a permanent link in a course to be able to access these resources at any time. Fine - I upload the resources and add a link to them in the course. I also want to access these resources each term. I have Autum, Spring and Summer terms - each has it's own course and I have to upload the resources 3 times, once to each course. I'd simply like to upload them once and be able to link to them from each of the 3 courses. I have resources used to support cross-curriculum teaching, e,g, a flash video of the best images from the year shown on MSNBC - I used this in both art and in literacy lessons (for writing headlines) so I had to upload it twice, once for each course.

Is a solution being worked on - yes or no?

In my experience working on a large number of projects (various sizes/different industries/different technologies(real-time, embedded/win32/parallel processing/web-based) over 16+ years) I think it's an ominous sign that bug fixing and maintenance is apparently being neglected in favour or new development - I know all developers, given the choice, prefer to be writing new code but this is where project management and experience is important. With a large list of oustanding issues (of varius severities) it's much much harder to say how long it will take to get the current version of Moodle to a position where you would say that "major" new development should start. The issue of sharing resources (that I describe) is fundamentally important (and is the reason I consider it to be a major bug not a request for an enhancement) and probably fairly simple to solve - why has it been neglected for so long? If it's being overlooked now becasue of new development surely the argument follows that the same thing will happen after the next revision of Moodle - under what circumstances will it be addressed?

Is everyone else clear that we are talking about the same problem here?

All good points.

I think the answer to your question is "No", other than the work being undertaken on the Repository API.

WRT bug fixing and maintenance vs. new devt. this issue is already recognised and being addressed. I suspect that we'll see less major changes and the frequency of releases slow down from here on. A lot of the new development of late has been to make Moodle more scalable and sustainable for the future.

I'm not sure if you're referring to the number of issue sin the bug tracker with this statement "With a large list of oustanding issues (of varius severities) it's much much harder to say how long it will take to get the current version of Moodle to a position where you would say that "major" new development should start." I think all similar software will have a multitude of issues, with Moodle this may seem like more as the process is entirely open and visible to all.

http://docs.moodle.org/en/Development:Repository_API

It's obvious that many people need this (look at the votes on this bug) and it's just as obvious to me that the Moodle with good repository support + a good repository will solve everyone's issues.

So I look forward to you all helping us define the Repository API in detail and helping us shape and test the system for Moodle 2.0.

Please start by reading the spec and helping to come up with use cases that we haven't described yet. When you're happy with the spec vote on MDL-13767

I flagged this as "duplicates" the repository api, based on it being the nearest match; but it doesn't do what the repository api does - rather provides a function that the repository api will enable, more fully, in the future. I hope this will solve some simpler needs for Moodle 1.9.5 users in the meantime.

Feedback is welcomed, please!