4 ms·

This is misapplying the unix philosophy. There would be too much duplicated functionality between different tools for different sites. It would be like having

by ldarby 6y ago

This is misapplying the unix philosophy. There would be too much duplicated functionality between different tools for different sites. It would be like having different versions of /bin/ls for different file systems.

ldarby 6y ago
To follow on, it's a valid point though. /bin/ls can handle different file systems because many other separate people/projects are responsible for the file system specific support (in the kernel). Youtube-dl should be architected to allow many other people to own the site-specific support (i.e. via a plugin system, with the main "distro" of yt-dl including some popular plugins, which other people or themselves are responsible for), if it was like that then probably this fork wouldn't be necessary.
- theidel 6y ago
  Yes that is a good point. The architecture is not fully suited to the current situation. There is actually already a base structure so it would only need the plugin system which pulls the missing extractors/downloader on the fly. Tho I may see problems here when it comes to windows binaries. Another advantage would be to easier maintain those extractors as well as all issues that arise around specific ones. So no more thousands of issues addressing different extractors in one project.
noxer 6y ago
"too much duplicated functionality" What should that be? Who decides when its too much anyway? No one cares about duplicated functionality in stuff they don't use. Probably 90% only want to download form YouTube. So why would they care if part of the code is used in another downloaders they don't use. If you create a kernel/OS/Distro sure you don't want duplicated functions but this is just a downloader tool. Also if there are generic functions that can be used by different tools you create a lib. No one has to reinvent the wheel. Would it cause more work if summed up? Yes most likely but the work is shared and independent.

by ldarby 6y ago

ldarby 6y ago

To follow on, it's a valid point though. /bin/ls can handle different file systems because many other separate people/projects are responsible for the file system specific support (in the kernel). Youtube-dl should be architected to allow many other people to own the site-specific support (i.e. via a plugin system, with the main "distro" of yt-dl including some popular plugins, which other people or themselves are responsible for), if it was like that then probably this fork wouldn't be necessary.

theidel 6y ago
Yes that is a good point. The architecture is not fully suited to the current situation. There is actually already a base structure so it would only need the plugin system which pulls the missing extractors/downloader on the fly. Tho I may see problems here when it comes to windows binaries. Another advantage would be to easier maintain those extractors as well as all issues that arise around specific ones. So no more thousands of issues addressing different extractors in one project.

noxer 6y ago

"too much duplicated functionality" What should that be? Who decides when its too much anyway? No one cares about duplicated functionality in stuff they don't use. Probably 90% only want to download form YouTube. So why would they care if part of the code is used in another downloaders they don't use. If you create a kernel/OS/Distro sure you don't want duplicated functions but this is just a downloader tool. Also if there are generic functions that can be used by different tools you create a lib. No one has to reinvent the wheel. Would it cause more work if summed up? Yes most likely but the work is shared and independent.