Moodle

Oh, the other thing was that it wasn't obvious how to actually implement send_package! Where the files were etc

1. Are you talking about code or authentication? Code is not a big deal I think. Boxnet for example should be moved into lib/ out of repository/. authentication is a bigger problem but we talked about it a lot and didn't really come up with a good solution.

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.

(sorry for slightly poor comments- was getting thoughts down at 1am )

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.

Plugin authors should be able to be lazy - the difficult things should be handled by the api wherever possible. Anything I can do to make the portfolio api solve the difficult problems so that plugin authors should be able to be as lazy as possible, I want to do... however I kind of think that forcing a plugin author to implement an abstract method is actually a way to let them be lazy as the code enforces it.. rather than make them search through the docs to find .. how do I hook in at this point to do xyz. (I'm talking about prepare_package here) - I aimed to make it so that you could implement 99% of plugins just by creating a lib.php and finding x abstract functions you had to implement, rather than reading all the docs. I'm not sure if that's the best approach but I kind of think that would be easiest for me.

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

gah, parse error, I missed a closing paren!

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

I think that your design is good - particularly reinforced by the fact it didn't take me very long at all to implement this plugin and I didn't exmine the docs thoroughly

I've created MDL-16391 about point 4)

can we close this since:

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.

We can, although I was kinda making this bug as 'new feature' tracking bug, and then I ruined it with unrelated general comments

thanks!

split comments into other bugs and created MDL-16417 to track development of the plugin