On 09/03/16 10:11, Arne Babenhauserheide wrote: > Am Dienstag, 8. März 2016, 22:18:22 schrieb Bert Massop: >> On 08-03-16 21:29, Arne Babenhauserheide wrote: >>> So I see two ways forward: >>> >>> >>> 1. Just live with the limitation of browsers and limit m3u to external >>> applications. >>> >>> 2. Do content-filter-magic and conjure up some javascript during >>> filtering which makes audio-tags with m3u work as if the browser >>> support existed. >>> What do you think? Should I go for the first or auto-enhance the >>> audio-tag in freesites? >> For now, I'd suggest to go for the first. Both HTML audio and basic >> streaming would work, just not together. > Since no one else wrote and this is the path which is much easier for me and > allows merging the feature more easily, I’ll chose the first then :)
I think we should go down the javascript route eventually, provided that Freenet continues to work acceptably without it. Whether to use javascript is already configurable, and Ian periodically starts a flamewar by suggesting we rewrite fproxy in whatever the latest Javascript-only framework is. However IMHO we should use Javascript where it will significantly improve things, which is true of embedded audio/video. I believe there is some unmerged work that goes some way towards this, some sort of framed video player thingy? Possibly from sajack? >> I don't think we need more Javascript in core FProxy at the moment. If >> auto-enhancing anything, please do so in a separate plugin. > Plugins for filter-enhancements sound interesting. > >> It might be >> an idea to remux the separate files (assuming they are of the same kind) >> and present them to the browser as a single file. Note that for MP3, >> this is a simple matter of concatenation. > That would not allow sharing data in multiple playlists, so I think it’s much > weaker than actually using playlists. Future ideas for the m3u filter could > be to allow any Freenet key, so multiple sites could use the same files > without having to encode redirects in the manifest. It would also be slow and unreliable, although we could probably avoid fetching the whole playlist before starting. A javascript front-end is preferable in a lot of ways. For example, for video, even if segments are lost we can present the segments that are available. > But it’s a possibility which Freesite authors could use right now, which > gives it a big advantage. So that’s OK for me for now. > > Best wishes, > Arne > -- > singing a part of the history of free software: > > - http://infinite-hands.draketo.de
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
