From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id ALBkIktu0F5bZwAA0tVLHw (envelope-from ) for ; Fri, 29 May 2020 02:07:07 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id nwo6Hktu0F46RQAA1q6Kng (envelope-from ) for ; Fri, 29 May 2020 02:07:07 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C2EFE9400B1 for ; Fri, 29 May 2020 02:07:06 +0000 (UTC) Received: from localhost ([::1]:38606 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeUQK-0000p0-Mo for larch@yhetil.org; Thu, 28 May 2020 22:07:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53312) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jeUPp-0000oc-9V for emacs-orgmode@gnu.org; Thu, 28 May 2020 22:06:33 -0400 Received: from [183.249.132.153] (port=1759 helo=localhost) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeUPo-0000st-05 for emacs-orgmode@gnu.org; Thu, 28 May 2020 22:06:32 -0400 Received: by localhost (Postfix, from userid 1000) id 67FA9241AF5; Fri, 29 May 2020 10:06:24 +0800 (CST) References: <87sgflu2gw.fsf@gmail.com> <87r1v4wyy4.fsf@fastmail.fm> <87r1v4bodg.fsf@localhost> <874ks0vxpk.fsf@fastmail.fm> <875zcgugq2.fsf@localhost> User-agent: mu4e 1.4; emacs 28.0.50 From: stardiviner To: Ihor Radchenko Subject: Re: [Feature] add a new org-attach dispatcher command to offline save web page In-reply-to: <875zcgugq2.fsf@localhost> Date: Fri, 29 May 2020 10:06:24 +0800 Message-ID: <87v9kfsden.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 183.249.132.153 (deferred) Received-SPF: softfail client-ip=183.249.132.153; envelope-from=numbchild@gmail.com; helo=localhost X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/28 22:03:48 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: 53 X-Spam_score: 5.3 X-Spam_bar: +++++ X-Spam_report: (5.3 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, FSL_HELO_NON_FQDN_1=0.001, HELO_LOCALHOST=3.828, NML_ADSP_CUSTOM_MED=0.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: reject X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: numbchild@gmail.com Cc: Matthew Lundin , Org Mode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: 1.59 X-TUID: m1xYFhLGlSO4 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks, Ihor, your explanation is helpful a lot!!! Ihor Radchenko writes: >> My uneasiness has more to do with the specificity of the dependence on >> monolith and the way that is hard-coded into the patch. When it comes to >> patches, I think priority should go to those that are configurable, >> accessible, and useful for everyone as opposed to those that have >> hard-coded work-flows or highly-specific user configurations. > > Agree. Though I can see a use of having monolith as one of the options > to help people discover what kind of tools they can use. I personally > had a hard time finding command-line cli like monolith. Actually, it is > the first time I heard about some offline tool handling js without a > need to write python or ruby code.=20 > >> The question is: which functionality? A simple downloading tool or a >> full archival tool? Achieving similar functionality to org-board or >> monolith would a big task, since they aim to download an archival >> version of a webpage (including all resources).=20 > > My view on this is bare-bones download, in a spirit of org-attach > itself. There is already 'url method in org-attach-attach, but it is > hard-coded to url-retrieve-synchronously. It would be handy if user > could configure alternative retrievers (like monolith, wget, curl, or > some user-defined function). > > Note that monolith does not crawl the website. It only collects > everything needed to show the page as you see it in browser into single > html file. This behaviour is what one expects to obtain when saving a > full web-page from browser. > >> In addition, with >> archiving you also quickly run into the complexity of versioning based >> on time archived.=20 > > I guess that org-attach-git can be used for versioning, but I don't > think that versioning is within scope of this patch. Monolith does not > even support versioning. > >> There's also the challenge of mapping the downloaded >> files to metadata (specifically the original url). Org-board currently >> handles both of these very well. > > org-board is a great package, but it is not built-in. I do not think > that all the org-board functionality needs to be included into > org-attach. At least not within scope of this patch as I understand it. > > Best, > Ihor > > Matthew Lundin writes: > >> Ihor Radchenko writes: >> >>> It does not mean that attaching URL directly is not worth including >>> into org. This sounds pretty common use case, especially considering >>> the number of packages providing similar feature. You mentioned >>> org-board, but there is also org-download and org-web-tools. >> >> My uneasiness has more to do with the specificity of the dependence on >> monolith and the way that is hard-coded into the patch. When it comes to >> patches, I think priority should go to those that are configurable, >> accessible, and useful for everyone as opposed to those that have >> hard-coded work-flows or highly-specific user configurations. >> >>> I agree that monolith is completely uncommon tool and I would not expect >>> the majority of users to have it installed, but the same functionality >>> utilising built-in url.el (as a default) should be acceptable. >> >> The question is: which functionality? A simple downloading tool or a >> full archival tool? Achieving similar functionality to org-board or >> monolith would a big task, since they aim to download an archival >> version of a webpage (including all resources). In addition, with >> archiving you also quickly run into the complexity of versioning based >> on time archived. There's also the challenge of mapping the downloaded >> files to metadata (specifically the original url). Org-board currently >> handles both of these very well. >> >> I suppose there would be a few options depending on what the aims are: >> >> 1. At the simple end, include little more than than a quick and dirty >> way of downloading a single resource (html, pdf, jpeg) using url.el >> or wget (or optionally, monolith) and putting that in the attachment >> folder. Those who want full archiving of all resources could use >> other tools like org-board or org-web-tools. >> >> 2. At the (much) more complex end, it would be to code out a robust >> archiving solution on top of url.el or wget. >> >> 3. Another, possibly simpler option... Add a command to the dispatcher >> that allows the user to invoke a custom function that is called with >> the attachment directory as the default-directory. This would enable >> more end-user flexibility, such as the ability to use >> wkhtmtoimage/wkhtmltopdf, monolith, phantom.js, archive.is, etc. >> >> Best, >> >> Matt =2D --=20 [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 =20=20=20=20=20=20 =2D----BEGIN PGP SIGNATURE----- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7QbiAUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsP+zQf/fR+EfMEqnXjb7GHaQFy6c7oKwYV6 ha8Wn4surO/drg5jgGXAyCpU72ru9Q1hKlxxlUYI/ZVexiCZU8U4masVHxOIbMWG 2PrtBAJgVcC87jrYufTF+bnWfDBmNMgMtpCALa4NQ2tH83vMKSkpBK42vRSIWK61 YUbGUD0aPdUCjVz5Cwa5xfZe2i9phPPg6ipjBCm+sIdzOeFL8Dj/34dtPW1G/sOE LTFyntcWn44xpb9mjSgN6EWC1Y9LJYSPTyP0PWVu5JXBoQfA+4vf5i7UakLurI46 +fBPPWNkb48yRc5i5OTxnI3Nxxk5YlQQbXZStMmKuqpIKmsNJsVjqfGa+g=3D=3D =3D8LEN =2D----END PGP SIGNATURE-----