From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id BD26F40393 for ; Mon, 22 Aug 2022 09:12:58 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 898FD68B9AA; Mon, 22 Aug 2022 12:12:55 +0300 (EEST) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id F31CA68B75A for ; Mon, 22 Aug 2022 12:12:48 +0300 (EEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id D0FAD44B96 for ; Mon, 22 Aug 2022 11:12:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=acc.umu.se; s=mail1; t=1661159567; bh=fiIEWfvIPqqd9TaeZRZq7IivQLy3UyXIuSiFYmRD8IM=; h=Subject:From:To:Date:In-Reply-To:References:From; b=QUb4byuKB+7t0mkeaHNchImVUIDlkiLveTQyECfHhsa3ojPzpwl0SQ3DW9B2/rmeS sv4fRRoXST4Gac978du6Zkot5OfO0WimzSX8eXJX2Cd3VwjPHIkX0zYYrke6cMJcNt S9LWd9j6x1wWG7ipVZK5uv1nTqLdCk/cXSm83A7vW6yAlo3ru2K4uLZ+bZti9eUWUJ qIrIkQh/00+SMZ3weij8kAvHJ0IxBfdQuqIatB9JdXl6iblHGsIU3MTZNhcw1Vb4x8 bQEwlt6aOPV+59MEgcXEabH0enC9z0TGz4l1ZGtTmZs9+sEQTR0cIcFCCRAqH3FYzm Twp0WFWLvgDNw== Received: from [IPv6:2a00:1598:b021:4:2a3d:1e2d:2f3a:e03] (unknown [IPv6:2a00:1598:b021:4:2a3d:1e2d:2f3a:e03]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: tjoppen) by mail.acc.umu.se (Postfix) with ESMTPSA id 4D7F544B93 for ; Mon, 22 Aug 2022 11:12:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=acc.umu.se; s=mail1; t=1661159567; bh=fiIEWfvIPqqd9TaeZRZq7IivQLy3UyXIuSiFYmRD8IM=; h=Subject:From:To:Date:In-Reply-To:References:From; b=QUb4byuKB+7t0mkeaHNchImVUIDlkiLveTQyECfHhsa3ojPzpwl0SQ3DW9B2/rmeS sv4fRRoXST4Gac978du6Zkot5OfO0WimzSX8eXJX2Cd3VwjPHIkX0zYYrke6cMJcNt S9LWd9j6x1wWG7ipVZK5uv1nTqLdCk/cXSm83A7vW6yAlo3ru2K4uLZ+bZti9eUWUJ qIrIkQh/00+SMZ3weij8kAvHJ0IxBfdQuqIatB9JdXl6iblHGsIU3MTZNhcw1Vb4x8 bQEwlt6aOPV+59MEgcXEabH0enC9z0TGz4l1ZGtTmZs9+sEQTR0cIcFCCRAqH3FYzm Twp0WFWLvgDNw== Message-ID: From: Tomas =?ISO-8859-1?Q?H=E4rdin?= To: FFmpeg development discussions and patches Date: Mon, 22 Aug 2022 11:12:44 +0200 In-Reply-To: References: <20220810222708.186270-1-derek.buitenhuis@gmail.com> <612e12d2-4df2-a2fc-5560-7acd93c2fc8f@rothenpieler.org> <20220818143154.GF2088045@pb2> User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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-request@ffmpeg.org with subject "unsubscribe".