Portfolio API

This page describes the specification for a future feature, currently being worked on for Moodle 2.0. This spec is STILL UNDER CONSTRUCTION.

Overview

The Portfolio API is a core set of interfaces that all Moodle code will/should use so that we can easily publish files to all kinds of external document repository systems.

It's important to remember that portfolios are generally treated as WRITE-ONLY. All we are doing in Moodle is grabbing stuff and pushing it out to somewhere. Management of the files and further combining/reflecting is done through the native interface provided by the portfolio system. Reading of files from a repository is handled by the Repository API.

A typical user story:

1. When portfolios are enable, every page or major piece of content in Moodle has a little "Capture this" button beside it.
2. User clicks one of these buttons
3. User is able to choose from a list of configured portfolios (this step will be skipped if there's only one).
4. User is asked to define some metadata to go with the captured content
5. The content and metadata is COPIED to the external portfolio system
6. User has an option to "Return to the course" or "Visit their portfolio".

Note this will be just as useful for teachers as for students.

Architecture

Here is how it will work:

1. The admin can set up portfolio plugins over Moodlenet or any other mechanism as being trusted portfolios for this Moodle.
2. The admin can specify default portfolio for all users, and/or allow the user to pick one as well.
3. Small function like portfolio_add_button() can be called from throughout Moodle to add a small button labelled "Add to portfolio". Can be next to forum posts, assignments, quiz attempts etc.
4. Button links to central script portfolio/add.php with parameters to call back a lib.php function in the calling Moodle module, such as assignment_add_portfolio().
5. This function takes the arguments and uses it to create a file (native format or a constructed html) plus metadata like user name etc, which it returns.
6. If there are multiple portfolios or instances configured, then portfolio/add.php shows the thing along with "you are currently sending this to a portfolio, select one or more from the following" ... otherwise if there is only one, then skip this step.
7. portfolio/add.php then takes care of passing this data to the currently active portfolio plugin(s) (All in the directories /portfolio/type/xxx).
8. The plugin takes care of copying this data to the external system, and showing any screens that might be necessary, like more metadata etc, or perhaps just a simple message saying "your file has been added to your portfolio" with two buttons, one to return to where you were, and one to go further into the portfolio and start messing with it.

Thoughts on Plugins

Currently I am thinking that there are three separate potential plugins (note that *two* of these can be re-used across portfolio/repository):

1. System (eg Mahara/Elgg/OSP) - this is really portfolio/type/xxx
2. Transport (eg http/scp/cp/dav etc) - this could be re-used across both
3. Contenttype/manifest (eg IMS/Mahara native/Moodle native (0) ) - this could be re-used across both

The reason for this is that I can see it's pretty likely that the same "system" might talk both portfolio and repository, so it makes sense to abstract transport layer and manifest into separate plugins.

0: We're in the process of defining the way data gets in and out of Mahara as well - obviously this is partially to do with the Moodle Portfolio api development, but also the ability to transfer content between Maharas - similar to Moodle backup and restore. If one of the content types is "Moodle native" this could possibly eventually be expanded to include the moodle backups.

Brain dump

abstract portfolio base class

1. get_name
2. get_transport_types (returns ordered array of types to use as available)
3. get_content_types (returns ordered array of content types to use)

(these last two may want to be configurable by administrators)

more here, depending on whether we go with separate plugins for transport/content should be able to have multiple instances of each plugin type although these may be just mnet hosts which are subscribed to a particular service. Currently mnet services can be published or subscribed although I think that with repos being read only and portfoios being write only this may have to change.

Do we need a more elegant way to add application types to moodle (currently a record in mnet_application and an icon and some language strings)?

transport types

(note that we don't necessarily want more than one of these for the initial implementation)

1. http
2. filesystem (could be local/nfs/samba whatever) (cp)
3. ssh based (eg scp - should find and re-use the elgg block code as it deals with using ssh keys nicely)
4. webdav
5. open social? (http://code.google.com/apis/opensocial/)

content types

(note that we don't necessarily want more than one of these for the initial implementation)

1. ims?
2. leap/piop? (http://wiki.cetis.ac.uk/LEAP_2.0)
3. moodle native?
4. mahara native?

transport types and content types should be able to be found in a shared location for multiple plugins of both portfolio and repository type to use, but also might be specific to one type of plugin (maybe) which means that moodle should support looking in multiple locations for these plugins.

See also

• Repository API
• File API