Talk:Portfolio API

Comments on specification

Please leave your name and indent according to reply structure.

Comments from Tim Hunt

Do we have to restrict it so that only admins can configure repositories

Here is an example user story:

A course somewhere out there about good online teaching requires students to participate in an online community, say, Moodle.org, and record evidence of their activity to their Portfolio. Moodle.org is a nice open place, so wants to help this sort of thing. Therefore, Martin configures it so that any user can go to their user profile, and configure any portfolio plugin for their own use, so students on this course can easily export from moodle.org to their own Portfolio.

Similarly, this may be a way to deal with Facebook authentication issues. Each student configures the facebook plugin for themselves, including some sort of secret key.

Do we really need transport APIs

I am not if transport layers really need to be pluggable APIs as such. Surely almost all Portfolio plugins will use a single transport method.

Of course, each transport method will have a library of code, for example a SOAP library, or the mnet libraries, and the Portfolio plugins will use these, but I don't see any need for all the transport mechanisms to implement some common interface. Different transport mechanisms work very differently, and tend to have different interfaces in their standard libraries. Trying to put a common wrapper round all of them seems difficult and unnecessary to me.