Mihai Sucan is doing an amazing job with his Paintweb GSoC project. It is really outstanding, Paintweb has gotten much better, it works (fast!) on the XO, he's gotten it integrated with TinyMCE and it has all been fantastic.
Until now, and we're going in circles with something that has turned out to be much much harder than expected. Personally, I am a bit lost.
With Paintweb enabled, tinymce users can create or edit an image with their HTML. This is great -- except that we now have "attachments" to all these textareas... where do we save them?
Naturally, we want to add this support to any code that uses moodleforms with textareas, without having to add explicit support in every location in the code that defines a form. Unfortunately, I can't see how to do it...
We can post the images base64 encoded with the form, or save them ahead of time with an ajaxy entry point.
We need to keep them with the textarea. Modern HTML supports 'dataURLs' which means that the image is base64-encoded in the HTML. That makes resource management easy -- backup, restore, deletion, copy all work. But from a performance PoV it is a mess -- just the traffic from PHP to the DB goes insane. And we would have to "upgrade" all our textfiedls to a really large datatype because the images are big.
Even if we use dataURLs to store things -- which resolves the resource management, but is murder on our DB -- we can serve them separately by using a filter to extract the dataURLs and serve them as images, so they are cacheable, etc.
The images don't belong in course files, because only some teachers can store files there -- and this is fun for kids!
The images don't belong in user files -- they are clearly beign used in a particular resource - a modinstance for example.
If we are to store them separately, we need to figure out what 'data object' they belong to. How?
Naturally, there are security issues. Only serve the image when appropriate. Only store an image when the form submission was received and saved successfully.
Moodleforms is not a lot of help because it doesn't know what table and id we are editing (when editing) and in the case of new records, we don't have an id. And of course it may be a complex bit of data that lands in 3 tables.
Mihai hasn't been short on ideas, but I had to shoot them all down -- which I definitely don't enjoy doing.
...What to do?
My only "bright" idea is to have a single call right after every successful insert/update, where we say
update_image_blobs($tablename, $recid, array( $rec->sometextfield, $rec->othertextfield))
And that would feed into a "reference trcking" table. Backup/restore code would then be able to take hints from there.
We could also run through the whole DB on a cronob to build or 'reference tracking' table. That sound? It's my teeth grinding at the idea
Or we could use a content filter to build the ref tracking... except that the flter code has no idea about the table-and-recid.
On the access control front we do have a reasonably good approach to ensure we only serve images to users who can see the HTML that they are associated with. The images are named (and served) with the sha1 of their content, and are not browsable. Because of that, you can only know the url of an image if you have seen the image.
Naturally, someone can share the URL with others... but that would be equivalent to sharing the image itself, which people can do anyway. This is the one case where obscurity seems to be a good mechanism for security. (Until Petr beats me up about it )
Overall, we need a reasonable plan that doesn't involve ripping apart all the forms in moodle.
Ideas? Please?