- I agree output should be more of a service and we should support more rich embedding via whatever the host server supports ( not what the local client ) supports.
- Timed Media handler does not jump though too many hoops for embedding per-say... because it separates embedding representation ( html5 video tags ) from player interface ( mwEmbed player ). But it certainly would be helpful to fix up media Handling so that you could embed videos from commons on your local wiki without having to keep an up-to-date copy of TMH.
- For example adaptive streaming should start being supported in html5 browsers. Would be nice if the embedding service included the code to do this ( instead of having to update your extension )
- In terms of output api formats, we should also think about open graph xml ( as well as oEmbed api entry point ) Open graph would support embedding into everyone's 'favorite' social network.
Talk:Requests for comment/Refactor on File-FileRepo-MediaHandler
Sounds good overall... and good to hear that TMH is less hoop-jumpy. :) Sounds like we should be able to embed (hah) MwEmbed into the embedded iframe to handle the player logic and otherwise make that pretty straightforward for ForeignAPIRepo and oEmbed clients. :D
For Facebook/OpenGraph I'm a bit unclear on whether we'll be able to trigger a direct media player per the stuff on https://developers.facebook.com/docs/opengraph/#types but we can get to the details later! I'll throw a bugzilla entry in to stash more notes on later.
bugzilla:31338 <- feature req for open graph <meta> tags w/ thumbnails/videos
Some notes from Friday at NOLA Hackathon/Friday#Swift_media_.26_stuff
@brion Thanks for fixing bug 31282, even if an ugly hack, for tiff thumbnails on local/remote repo. I also very much noticed inability to include video thumbnails on my local wiki from Commons with my configuration or whatever reason. I'm happy to see these issues getting attention. :)
I don't know how much hacking I can do but at minimum could help out with testing code. Cheers. Aude 01:19, 4 October 2011 (UTC)
Glad to help :DD
Access control is something that seems to come up a lot for media files. It seems that our community wants something like workflow systems, where the file remains mostly intact through its journey, but where not everyone has access to the file all the time. This isn't just Commons, it comes up in the avatar discussion, even the coding contest promotion spec. And workflow systems require very customized access control.
Right now we have a very unintuitive concept of zones, which is a limited menu of different kinds of access patterns, and you have to "physically" move a file to change the access control. It's very tied to the idea of directories and apache config, barely an abstraction. Which makes it efficient.
If you were to start from scratch you might want to design Files with access properties that were proper to the file itself. This may be incompatible with our caching strategy, since that involves PHP and even a database hit to determine who gets to see this file. Just a thought for now.
Definitely worthwhile examining, though probably a couple more steps beyond what I'm proposing here. (Will also need more thinking on namespacing etc.)
There are no older topics