2. I guess it doesn't have to be abstract but I kind of think that at least plugin authors should be thinking about this enough even to implement it to just return true. It could be zipping up files or writing out a manifest or anything....

3. Yes. It could. I am having a bit of trouble with expected time actually, you'll see that most of the callers have todos in it.... the problem is that it is called before prepare_package, which means that the base class is not going to be able to find the files. Also in some cases it's called when the content is still in the database. Remember this function is called both in the portfolio plugin and in the caller..

4. Ok, I did a lot of work in that area on Friday to deal with the flickr plugin and images/videos - what exactly do you mean as 'working as planned'

5. Yes, that would benefit from documentation. I'll add some notes shortly. In general if you find anything else where you think the docs are lacking, please feel free to update the docs as you write code.

Thanks again for the testing.

1/ A bit of both - I think we have come to a bit of a conclusion of storing a key as a user preference, then handling the revoke of the key with a user delete event. (Had forgotten about the events api )

2/ Fair enough - was just being a lazy plugin author

3/ Hmm - again I was being a lazy plugin author

4/ I was having trouble getting things I thought were text not able to use the plugin when I had the format set as FORMAT_TEXT. But I didn't investigate very thoroughly - more of a todo to check if it was a bug.

the expected time thing is another matter... we could just make a function in the base class or a helper method or something that you pass an array of stored_file objects to and it returns you PORTFOLIO_TIME_* ... but that doesn't take database size into account (for example exporting an entire glossary as csv) ... I guess it could cover most of the cases though. I will add notes to the 'audit expected time' bug.

Actually, there are two issues here:

1. expected time in the callers - could be solved for most cases using above method
2. expected time in the plugins - this is really used to do things like force queued transfers (mahara can do this for example if it wants, it can make a decision based on server load or time of day or whatever and send back, 'yes, you can transfer content to me but you must queue it', or in the case of the download plugin, it overrides whatever the caller has said because you have to go through the process without queuing so that the user can download the file at the end. It's not really based on file size or amount of data to export, more the way the code interacts with the remote server or system.

Since you were writing a portfolio plugin not a caller class I guess you're talking about 2 in which case you should just trust whatever the caller gives you as that will (should at least, it probably has a TODO next to it) take filesize/content size into account

hope that clarifies

Imagine I had added a closing paren after '... so that the user can download the file at the end'

1. was resolved (user prefs)
2. was resolved in discussion
3. moved to MDL-15833 (and I committed a big patch this morning that resolves it I hope)
4. MDL-16391 as you say
5. I updated the docs.

thanks!