Identify pieces of Scald to adopt/merge

I'm not convinced on the scalability of the drag-n-drop popout interface with large number of media items, although its good to see something different.

I tried the demo site but I ended up being very confused by the terminology (atom as in ATOM XML feeds?) and the interface. It wasn't something that was immediately intuitive for me, especially since I had several problems with the drag & drop working because half the time my browser things I'm trying to select text.

It would be good if others that maybe had a better chance to play around or know it better could maybe help highlight the main differences or key features that we can investigate.

Just a quick reply on three points :

• Scald has been designed to handle huge quantity of media content in mind. First for the Chicago public radio ( Vocalo ) then for radio france. There is a filtering capability provided by views to filter the media a user wants to find in his library for DND. On production, using the D6 version we also combine this exposed filters with the views savedsearches module to save filterings and provide a quick way to authors to get their media assets.
• Atom is more a D6 vocabulary terms we used to define a unitary piece of media content ( image / video / whatever ). On D7 this is now an entity ( not a file entity ). Atoms on D6 have a display context feature ( web / mobile / ... ) and a proper cache system.
• The current demo website is a D6 version with the old UI, we are going to update it pretty soon. I'll put a message here when it's done

Thanks drico. I'll try and get the D7 version running on a local install until the demo site for D7 is up in the meantime. Is there any demo video available for the D7 version at all showing the capabilities?

Dave, for easy installation, a module scald_quickstart was written.
The screencast is expected, but is not yet done.
Note that version 7 is not at all complete.
Do not hesitate to ask us questions

Thank you to Damien for this issue

@DamienMcKenna, @drico

The historic design adopted for the ScalD module was about creating its own entity system (atoms) because at that time (pre-release D6), the node API was unable to handle huge media collection the way we wanted.

Then came the entity API in D7 which was very similar to what was developped with atoms in the D6 module.

We thoroughly looked at the media API before deciding to port ScalD to D7, but you're right, the use of File Entity was a blocker for us because :
* We didn't want every file on a drupal instance to be a media : the use of File Fields and Image Fields had to stay possible without these fields to feed the media library by default
* The approach "A media is defined by a file" was not the way to handle the use cases we've encountered so far. For example, a video hosted by Youtube is a "media without a file". The use of entity also allowed us to extend basic media properties, making them fieldables
* We were not comfortable with only being able to categorize media assets with their mime types.

Once again, Scald has been there for a long time on D6, and could not "by design" be ported to media, which was our original plan for D7.

The approach "A media is defined by a file" was not the way to handle the use cases we've encountered so far. For example, a video hosted by Youtube is a "media without a file"

If you think about it, you have to upload some kind of video file to Youtube, so yes, there is a file somewhere on Youtube associated with that media, which is why re-using files still makes sense. Just the file doesn't exist locally, that's all.

I talked a bit with people from scald a couple of months ago. I asked the same question as #5, the main thing that came up during our discussion (which wasn't thorough) wasn't the file-association but the hard-coded mime-type categorization.

If we don't want all images to share the same fields, I personally don't know how to do that with file_entity/media (that said I'm not a scald user either so I don't know the implementation details on their end). I completely understand why the mime-type categorization is relevant, but the fact that it's not easy (impossible?) to not use it when necessary is/was an issue for scald.

Yep, we're working on that in the File entity module with #1292382: Make it possible to create any number of custom File Types and #1260050: Provide administrative UI for adding/removing file types. The problem with possibly having multiple conflicting file types is determining which file type applies to a file if it could be multiple types.

If I understand correctly, that issue is about to create general mimetype ('image' for 'image/*' and 'twitpic' for example), but not the other way: one image/jpeg file is used in the 'Image' category, but not other image/jpeg file.

Solution is to use the file_entity module as described