Basic concepts:

  1. Single and logical way of handling different media: Images, Audio, Videos, other files (attachments)
  2. Flexible metadata structuring – support standards for each industry, but allow customization for each news organization
  3. Decentralized physical storage (on server, off server, on multiple locations at the same time with only one being active, — allowing for load balancing in the future?)
  4. Full API for accessing media files
  5. Mass import and and export of any type of media
  6. Full availability of metadata to web developers

Option 1: Use Campcaster code and keep database compatibility with Campcaster

pros:

  • initial faster development (reuse 95% of the code)
  • compatibility with campcaster at the storage level (database and files)

cons:

  • the campcaster version stores XML files – metadata has to be converted to an XML file before insert/modify/delete => much slower data access
  • too many records for a single file – many of the records created for unneeded XML file storage => slows down the database
  • still have to modify the existing classes to use campsite cache

Option 2: Write our own implementation from scratch

pros:

  • will implement only the metadata storage, data access faster
  • will be easier to maintain in the future as the campcaster implementation is quite complicated (unnecessarily)

cons:

  • incompatible with campcaster at the database and storage level – can still transfer files through the XML RPC interface
  • more time needed initially to write the code

Option 3: Mugur’s bright idea

  • use the campcaster multimedia storage as it is (it would still need some changes)
  • campsite would interract with it through XML
  • the slow operations (insert/modify/delete) will only happen in the admin interface anyway which doesn’t need excessive speed
  • cache the metadata in the campsite database – as we actually do for audio attachments currently, so we still have:
    • fast article search based on metadata
    • very powerful multimedia search (without linking it to articles)
    • fast attachments lists (since the attachment data is stored locally in campsite)
    • cached lists
  • the search user interface would still need to be adapted to Campsite
  • improve the existing storage engine to work with all metadata (currently it can only read audio files)

Mugur’s other notes: 3-4 weeks to make all the required changes and test the storage module, compared to 8+ weeks to rewrite from scratch. Actually even in the rewrite I would still use about 10% of the code, but let’s not make the storage our project now. We could use the current storage which is good enough, and make it independent. Later, if and when we have money we can rewrite it We could even implement the multimedia support as a plugin in campsite although this is pretty basic need nowadays to put it in the core package and it would be faster in the core package. Plus, this way we can drop the old ways of adding attachments

Reuse of MMA in Campsite (third option)

The MMA will be modified to use MySQL instead of PostgreSQL as a database server.

We will use the XML-RPC API (see AudioclipXMLMetadata::Upload) but instead of xr_storeAudioClipOpen we will use xr_storeMediaFileOpen which has the same signature but with an added parameter.

E.g.: xr_storeMediaFileOpen($p_sessId, $p_gunId, $p_metadata, $p_fileName, $p_checksum, $p_fileType) where $p_fileType can be:

  • application
  • audio
  • example
  • image
  • message
  • model
  • multipart
  • text
  • video
  • webstream
  • playlist

$p_fileType is the type from the mime type return; e.g.: audio from audio/mp3

See mma/DataEngine.php, line 74