fre 2022-08-19 klockan 14:52 +0200 skrev Mark Gaiser: > > > I believe we went over this in detail during those patch rounds when > this > was brought up (by you?). > I didn't go back in the archives to find it, but some reasons that > come to > mind: > - just handing the mere edge cases would make that bash script > complex > - potentially involving regex > - add in gateway detection logic and you'll have a bash script that's > likely more complex than the current ipfsgateway.c code. > - not cross platform by any means
Not our problem > I don't understand the argument of "ipfsgateway.c amounts to business > logic > that does not belong in lavf". Earlier arguments in this very same > thread > argues for far more "full" ipfs support, isn't that contradicting? > How can > a "full implementation" then ever be acceptable with that same > reasoning? I > honestly don't get that so please do educate me in this regard. I'd actually argue that in that case we should link a library that implements IPFS, not split developer effort by trying to implement it ourselves. > > For the sake of the argument and because I'm really curious to know > too. > Say we want to go for OS level support of IPFS. Just in the mindset > of the > meaning of "OS level" gives the impression that it would magically > make > IPFS work everywhere on the OS. Say, again for the sake of the > argument, > that actual OS level IPFS support does that magical behavior! Sweet! > I want > it! How? > - Can it be mounted as special directories? Say for example on /ipfs > and > /ipns.. Yes! But that makes this a linux specific support that won't > work > for windows. Which means this option isn't ideal. > - Can there be a global ipfs:// and ipns:// protocol handler? If that > even > exists, thathandler would do "something".. how would that be > supported > across different applications? Say chrome, file browser and ipfs to > name a > few. Or would that magical handler just return a file descriptor > where > every application is supposed to be able to use file descriptors? > - Any more OS level alternatives? A better way of handling this could be FUSE. How exactly to implement protocol handlers at the kernel or (more likely) systemd level is a discussion for those projects. Probably dbus shenanigans resulting in file descriptors. I don't hate the current gateway solution enough to want to delete it, since its current state of not having a default gateway won't cause unexpected security problems for users. But I also deliberately chose not to push the patchset because I didn't like it, because the proper solution belongs elsewhere. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
