From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id F/aaGc+fQmMKtQAAbAwnHQ (envelope-from ) for ; Sun, 09 Oct 2022 12:17:51 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id aBTLF8+fQmNHHQAAG6o9tA (envelope-from ) for ; Sun, 09 Oct 2022 12:17:51 +0200 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 CA424156A4 for ; Sun, 9 Oct 2022 12:17:50 +0200 (CEST) Received: from localhost ([::1]:58556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohTNW-0005Gp-2g for larch@yhetil.org; Sun, 09 Oct 2022 06:17:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohTMi-0005Gd-Rp for emacs-orgmode@gnu.org; Sun, 09 Oct 2022 06:17:01 -0400 Received: from stw1.rcdrun.com ([217.170.207.13]:57951) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohTMd-0002Ii-9k for emacs-orgmode@gnu.org; Sun, 09 Oct 2022 06:17:00 -0400 Received: from localhost ([::ffff:197.239.6.155]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000BBD14.0000000063429F92.00000866; Sun, 09 Oct 2022 03:16:49 -0700 Date: Sun, 9 Oct 2022 12:54:51 +0300 From: Jean Louis To: rswgnu@gmail.com Cc: David Masterson , Samuel Wales , emacs-org list Subject: Re: Org and Hyperbole Message-ID: Mail-Followup-To: rswgnu@gmail.com, David Masterson , Samuel Wales , emacs-org list References: <813D3F10-3E3C-497F-9FD8-FE0DA13C2970@gmail.com> <10960EC2-D614-4826-A277-79E963969345@gnu.support> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.7+37 (a90f69b) (2022-09-02) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1665310671; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=LASA8lkBglWfsuL7f0k1Ly1T0uoX/+1UfSPVx7Rhxmo=; b=hfBxqQPd8IMI7Z4iAsq823U2Zi6y0XWWVKZs4a9sbQAdGTXd5MSI+sO1PtpFyoXermfku+ wE4/5mNsR9pLxn9ELzk31JtF+3wbaZABfe1ROMo+0xO4vXAq6sd8PRNo/WwdFF+Ncpc1eg EbXzV9ismW3p8D0jwX40XQG88C6nHZAt0/ldkgtNvy0AtoJlQuipy9yDgW4n6VmEfEjeo3 e14MAhUltDyA3KIbnUiQrWck0Yr3GumJDmdmUEUQJXVftffmeKVh+lpRfi2BpiXw1kzv0Y Ep3NojFJ/MGa8Mll/Y9w5PGyZmhqR7g9XFvwoR4xiRlZJZ1XHiSVhirSms0/xQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665310671; a=rsa-sha256; cv=none; b=Ek/Gj0eq2a6s/x4V0Y3G8vbshzKf96TlTEmR75NV1fyIGnhnanLQpw5qVIUQHkAtFPNLee +KMGF4wzbwgZcygoITzSACQU37gRuhjpPlElqrRlH63iabUenk94BgEERTuGVNQiOu+QHd mYkul+Y87zB06r5b5UETy9mYEmlkiLxHZVVF4Wx5fiOiKA0vySvdvo1l2PduUebGsh5FEY KKM4Zzntb+6FEtB+vQCn1iY8wXOr29lbjCXLaV/DZbhDXSHKEYbEk+qXcW/rzcWCwSNbT4 uEh52nNqPR12mzyGuhdmwOj4Qf8LLFFGiCepmwsincMaPtKszdusEcp9kVvG1g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.98 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: CA424156A4 X-Spam-Score: -1.98 X-Migadu-Scanner: scn0.migadu.com X-TUID: Ty9dsFRAI1Z+ * Robert Weiner [2022-10-09 00:06]: > We had object-based, multi-media files with Engelbart's NLS/Augment > system. We had relational databases way before the web. > > But here we are in 2022 with enormous personal computing power and for > interactive editing, everyone is using and transferring stream-based files > of characters that are then interpreted at the delivery site. Alright, though I do not see relation from transferring files to databases. Just any digital information may be transferred to delivery sites by many different means. I understand that two paragraphs are related and I inject my thoughts in maybe not proper place. > There are many reasons for this including limits in many > organizations of the file types that may be transferred through > common protocols and the difficulty of maintaining relational > database or structured file type schemas across time. I can't see how relational database is more difficult to maintain then for example Emacs itself. Emacs is master of difficulties for computer user. For example I have not touched configuration files for PostgreSQL since years, if not decades. I start wondering why. Backing up relational database is so much easier than backing up plethora of apparently randomly dispersed files. It is just single command line or click on some graphical interface. Just do `pg_dumpall'. Let us say I wish to backup all the information that Hyperbole created in various directories, on computer, is there such option? Missing. We can't compare apples and eggs, but I have to give you for thinking. Hyperbole buttons in their files are underlying structure, user need not know anything about it. User has interface and uses higher level interface functions. But let us analyze it little that way. If you have a Hyrolo file, what you can do with it? You can send it to somebody? But that somebody need to use what? Emacs or any editor to work with contacts. Today users use mobile devices, they exchange structured contact information by using vCard format, and users of many mobile devices can accept contact information from other operating systems and import in their phones as one or multiple without problems. Hyrolo can't transfer contact information. And why? Because it is written more or less freely in the text file and it is not structured. We don't speak of maintaining Hyrolo -- that is not easy task really, it needs GNU Emasc which has so many dependencies, then it needs Hyperbole, then user can handle Hyrolo. What I want to say we shall not think of complexities, issues of installation and underlying management by software are not concern for user. User shall be able to click and get application. That is what 50% of people using computers know, they have mobile devices, they click and get it. No thinking there, but I don't say it advances society that way. In any relational databases there are views and various exports and unlimited variations how final data may be presented to user. Let us say contacts, that may be transferred by using vCard mechanism. Various other formats are possible. Let us say I need to exchange tasks, that is what I do all the time. Nobody at delivery site need know that I have underlying PostgreSQL database, that is not their business. They will get the PDF, image, video, text, WWW link, ZIP, and similar. Delivery site will get it delivered in the format how they can read it. If delivery site needs full database, it is just matter of two commands pg_dumpall and pg_restore and even those commands may be automated. Full database is similar to file system. One does not share file system, one shares database entries. And how such entries are shared depends of the programmer and user. Thousands of entries from my database are shared through web server and as HTML documents. Program generates PDF files and text, and emails for plans, programs and projects, and such are shared by any type of communication channel. > Simple tends to win out over more powerful because few people want to bear > the cost of continual training to raise all of the newcomers to a level of > performance that they cannot teach themselves. Today people use structured information without knowing. Contacts on phone are structured. Even notes' applications on mobile devices are pretty much structured, usually stored in SQLited databases and exported in various ways. Much of information in any libraries, online databases, and personal computers is stored in such databases. > I like your model, Jean, and am a fan of such things but I am also > pragmatic and thus focus on building things that I think people will > consume within a given environment. In the Emacs environment we consume anything that is useful, it is wide open. Emacs 29 comes with SQLite built-in. That is advance, progress. We can progress all with databases. > In Hyperbole's case, it is base Emacs and nothing more. Emacs alone has many ways to store ordered and structured information. > If you are familiar with what it takes to standup a scalable web > application today (what everyone wants), you understand why that is > not a great model for systems where the users have to manage and > customize the infrastructure themselves. I can't. What I think is that you never tried it out and did not understand that database minimizes human efforts and errors. It minimizes our efforts also because many functions you have programmed for Hyperbole and many functions people do in Org are already built-in in the database. There are many various systems that use ordered information. Example is Leo editor: Leo programmable editor: http://leoeditor.com/ Leo editor vs Org-mode: https://leoeditor.com/emacs.html I guess it fully uses database and thus it can handle ordered information so much easier. I have examined hyrolo-add function, it only adds a single name to the file. And function is that huge. Here is function that adds name, email and description in the simple database: (defun my-people-add () (interactive) (let* ((first-name (read-string "First name: ")) (middle-names (read-string "Middles names: ")) (name-or-last-name (let ((result)) (while (not result) (setq result (apply 'read-string '("Last name: ")))) result)) (email (read-string "Email: ")) (description (read-string "Description: "))) (sqlite-execute my-db "INSERT INTO people (people_firstname, people_middlenames, people_name, people_email, people_description) VALUES (?, ?, ?, ?, ?) RETURNING people_id" (list first-name middle-names name-or-last-name description)))) And then we speak of internal and external complexities. But those are subjective opinions. What is objective is to see the how big is the code that handles purely text (and never reaches the point of being deterministic) and the size of code that handles equivalent functions using database. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/