-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all,
On 02/07/2015 11:42 AM, Jonas Smedegaard wrote: > Quoting Paul Wise (2015-02-07 08:36:48) >> On Fri, Feb 6, 2015 at 9:50 PM, Thorsten Glaser wrote: >> >>> I smell the chance to share… >> >> It would be nice if someone could contact all of the Python ones >> and ask them to merge their code. Same for all of the Perl ones >> and all of the other ones. > > Looking a bit closer, it seems there _is_ currently a single > download-only framework for each of Python, Lua and Perl plugin > APIs (youtube-dl, Lua and get-flash-videos, respectively): The > (only?) other related reusable framework seems to be python-pafy > which seems targeted special features of Youtube rather than > generic download from many sites. Yep, pafy is trying to get most out of youtube in CLI environment (notice that mps-youtube is around pafy and uses mpv | mplayer2 for firing up videos - there are plenty of options and the community around it is very healthy and productive). >> Even more interesting would be a standard for video downloader >> plugins so that video players like Totem and VLC could just play >> videos on these sites. De-duplicate all the things! > > libquvi offers Lua-based plugin API. Used by mplayer2, totem, > git-annex and older mpv (and possibly also rhtyhmbox and grilo). > > youtube-dl offers Python-based plugin API. Used by freevo, lives > and recent mpv. > > get-flash-player offers Perl-based plugin API. Used by no other > tools, apparently. From personal experience get-flash-player is > better than the others at "walking blindly", fetching videos from > random websites. I suppose you meant get-flash-videos? > Would be nice if someone... > > * rewrote site support in other tools as Python/Lua/Perl plugins. * > rewrote competing UI of other tools as libquvi/youtube-dl > frontends. * ported libquvi/youtube-dl/get-flash-player plugins to > each other. > > > - Jonas > What if someone takes a lead in contacting upstream developers of all this implementations and see if all can work together to one unique/universal software/library (something as Paul suggested)? Would that benefit the entire Free software ecosystem regarding this part of it? Or to let people develop what makes them happy (and fun!) and maybe we see some unique features in one that others don't have or that others just experiment it and so on? My stand is that it wouldn't hurt that we try to combine "forces" of upstream developers if we can. I am willing to hear opinions on this matter and would even take time to contact and manage upstream collaboration if needed. Cheers, zlatan - -- Its not the COST, its the VALUE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJU1iGrAAoJEC5cILs3kzv9IekP/AyFZzFxpN4l9K0gRNKzo75j 006sUSeancx4JMBTe2oRV28YBE8p/U8CNS2qCtnhr8Zd3GbTCoKlYV8k5TX3QZt9 TlcNIqJcH55DGWjMcWKdpLqDb/8JJ+cs2ZM012ennMGwm7m81ijwBg9uG8qluVoo XzCVbpW9C8E3GD8noIAY1Bxm3GCHr9n+CCi/iH1FciXOe/7EQRPF2SBlraWNsApM 9vDyDjfWn6cVPfS12NrHWy0TZYjn6a4qYGZT6WmVBL00iI4IJg77vkLjd7BrHZ0c 8QhuBoSUwJNu+X20KfJioWMZnES8qppKDOChP450QVwhm27wWUj6hUZtEw+BTIB4 vrHtqODlfhNsz/gZk6FjyKiPl+YWwbQEPGTGN6uu3YtBiOtoDss0vk6DDvZsQV0Y NB7kuQAkwvQozAqSLq7zddOpolK1fdpt8kJjdirmJNFj0zaxxaLwX+YOMszlu1MP HGxWZ3fn81WUz4h0zWJLmKSClH+6eDHhcN9JtAAsmgGO8JHfuhRKOp2pMuNS1rMU oMODIVB5re+qZkVyvuoaAR2uKfecb4UimRe6Of3k/NlFS1Xse4Oo1oj4HXIUdQVJ hxkb3ONacAJaHoblAdgtaqdO5fLoF/Fs7skwopUDRECkHaqwgdVBOSG7av2lm4Gp c+2cmNUXwDLkLX/7JHD0 =SCrA -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54d621ac.1030...@riseup.net
