Martin Dougiamas

Hi Phil,

i'm looking forward to seeing your code for this as GPL!  

As an example see the mp3 file attached to this forum post, rendered by forum as a player.

I think it might be better to simply use an "attachment" filearea (similar to forums here, but more compact) rather than embedded links in the HTML and buttons in editors.  This is actually what Facebook, G+ etc do.

I agree the current UI for comments sucks and would love to see a lot of UI fixes to make it more useful.  Most of the workflows in the specs are attractive.

I'm a little worried about adding HTML and files to every comment though.

The original comment system was designed to be lightweight and to work anywhere across Moodle.  Things it is missing intentionally:

1. HTML:  Formatted text in Moodle means allowing all editors, not just HTML.  And opening up to HTML means a lot of security around that, as well as a drop in performance and a more cluttered UI.  Note that Facebook, Twitter and Google Plus do not allow HTML in their posts, and no-one seems to mind.  I don't think the case for HTML here is good, and you'd need to make a good case for it if you want to keep including it.
2. Files: There is a slightly better case for files, perhaps, but again this will open up a  bit of can of worms with performance and security.  Comments can appear in MULTIPLE contexts (eg a comment block) and the capability checks start getting onerous for all the file access and handling. Not to mention a blowout in course sizes as all these "temporary" files flinging back and forth have to be backed up etc.

I do like that these features are optional and have switches, but this itself creates some complexity, and remember that changes here will affect a lot of modules in Moodle and perhaps cause a lot of new bugs later on.

As a result I'm wondering if the commenting you are focussing on, which is almost exclusively discussion between student and teachers over graded items, might not be a separate beast to the commenting API, perhaps a gradecomments or feedbackcomments.

This is the developing spec to look at and make suggestions on:  http://docs.moodle.org/dev/Logging_2

Most (all?) of the "realtime" needs that we currently use logging for can in fact be moved in new tables for that purpose, making them very fast.  That should free up the long-term logs to be huge and slow if they want to be.