From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id eMu6AVwyx18QSAAA0tVLHw (envelope-from ) for ; Wed, 02 Dec 2020 06:21:16 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id kHEfOVsyx1/JegAAB5/wlQ (envelope-from ) for ; Wed, 02 Dec 2020 06:21:15 +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 6371594043A for ; Wed, 2 Dec 2020 06:21:15 +0000 (UTC) Received: from localhost ([::1]:58244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkLVo-0003Hj-TB for larch@yhetil.org; Wed, 02 Dec 2020 01:21:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41938) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkLUo-0003HO-1Y for emacs-orgmode@gnu.org; Wed, 02 Dec 2020 01:20:10 -0500 Received: from static.rcdrun.com ([95.85.24.50]:56087) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkLUl-0003ab-Ll for emacs-orgmode@gnu.org; Wed, 02 Dec 2020 01:20:09 -0500 Received: from localhost ([::ffff:197.157.0.57]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0007.000000005FC73213.000040B3; Wed, 02 Dec 2020 06:20:00 +0000 Date: Wed, 2 Dec 2020 09:14:57 +0300 From: Jean Louis To: Ihor Radchenko Subject: Re: One vs many directories Message-ID: References: <87zh2zyqol.fsf@localhost> <87v9dkapbi.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87v9dkapbi.fsf@localhost> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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: , Cc: "Dr. Arne Babenhauserheide" , Texas Cyberthal , "emacs-orgmode@gnu.org" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: 1.22 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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-Migadu-Queue-Id: 6371594043A X-Spam-Score: 1.22 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: mAaugGjPLFkw * Ihor Radchenko [2020-12-02 05:53]: > > Jean Louis writes: > > hypothes.is is free software that may be installed locally. > > > > https://github.com/hypothesis > > Thanks. You inspired me to try installing it locally again. > > The main problem with hypothesis is that it is designed to be deployed > to a server and not to a local machine. Thus, the instructions imply > some knowledge of server configuration and skip several important steps, > which were not obvious for me without spending quite a significant time > googling for various issues during and after the installation. > > Anyway, I finally managed to get it working with my local setup. Next > step is Emacs integration... That is great to hear. I wonder how it can be integrated with Emacs as it is all Javascript based. Here is the Org version of: Technology Template Project OHS Framework as Org file http://ix.io/2GdW I suggest when making tools for Emacs that developer of the tool looks into the template for open hyperdocument systems that system are developed that they benefit most people. - "Open" :: implies vendor-independent access to the hyperdocuments within and across work groups, platforms, and applications. If such system is developed with the database backing and generic hyperlinks then database is vendor-independent (mostly, but it is still PostgreSQL, but could be any other because it is SQL), then it can work for any kind of groups, it can be accessed from various platforms by using Emacs, but it can also be accessed by browser, but also through other programming languages would such program be re-written. For Org, to be open hyperdocument system it would mean to spread it onto other editors such as Vim where basic Org mode already exists and other editors, and applications, such as those on Android like Orgzly that supports Org. But all that does not make Org yet open especially in relation to hyperlinks. Hyperlinks should be dynamic not static and centrally managed not user managed to be work over various platforms, applications, for various groups. Using hyperlinks like: file:///something/pdf:page 1 Is not portable for many. Such hyperlink should be dynamic, which means if user accesses the database from remote host such could not access such hyperlink. It would need to convert to ssh:// or scp:// or ftp:// or https:// hyperlink or something else. These types of hyperlinks would be better: user@hostname.com:PDF:Page:1 or user@hostname.com:PDF:Query:Title or user@hostname.com:PDF:Selection:1,2,3,4 but then again they are not enough generic. I am now making hyperlinks whihc are very generic, they can just designate the node number and server from the server list, could be something like: hyperscope:show:1:2 - to get the human designation of the hyperlink, what it is really. hyperscope:activate:1:2 - to go to server 1, node 2 and activate hyperlink. If I am on local file, Dired would open, but if user is accessing it remotely the hyperdocument would open in different way. That is what I mean with dynamic hyperlinks. hyperscope:email:1:2: - it would send it by email to the user. Because system identifies users with their usernames and other attributes hyperscope:email:1:2:user@example.com - it would send hyperdocument to other user if there are enough permissions In that sense of having generic hyperlinks one should also make annotations. If I make annotation on Emacs than such should be translatable to let us say Hypothes.is but if not with that tool, hyperlink for annotation could open on Emacs with Xpdf or Evince reader on specific page number while showing annotation in Emacs. Systems should work equally well in any browser because of their generic nature. Hypothes.is is now working on browsers, which is for me very limiting. They should be liberated from browsers as well. That means that API should be there that allows access through any interface.