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 gEXKLqn3uF9/IAAA0tVLHw (envelope-from ) for ; Sat, 21 Nov 2020 11:19:05 +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 eH3LKqn3uF8+DgAA1q6Kng (envelope-from ) for ; Sat, 21 Nov 2020 11:19:05 +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 5953C9403AD for ; Sat, 21 Nov 2020 11:19:05 +0000 (UTC) Received: from localhost ([::1]:45546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgQv2-00042c-0b for larch@yhetil.org; Sat, 21 Nov 2020 06:19:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgQuX-00042M-Ui for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 06:18:34 -0500 Received: from static.rcdrun.com ([95.85.24.50]:44221) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgQuV-0004yY-9U for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 06:18:33 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0006.000000005FB8F784.00003529; Sat, 21 Nov 2020 11:18:28 +0000 Date: Sat, 21 Nov 2020 13:21:08 +0300 From: Jean Louis To: Texas Cyberthal Subject: Re: One vs many directories Message-ID: References: <87y2ive1i4.fsf@localhost> 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.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: "emacs-orgmode@gnu.org" , Ihor Radchenko Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu 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-Spam-Score: -0.51 X-TUID: MNpVDeO51PIW * Texas Cyberthal [2020-11-21 11:32]: > Hi Jean, > > I'll use some of the concepts in the first half of your email. I > disagree with the second. > > > In my opinion directories should never bother user. User should just pre-define sets of directories such as: People, Groups, you name it, and files should be accessible in such directories automatically. > > Productivity studies show that navigation dominates search. Human > animals are natural pathfinders and walking computer paths with > ergonomic file explorers such as Dired increases mastery of the > subject matter. Do you mean that navigating file system dominates the search? I also think that navigating file system dominates the search if that is what you refer. I think that users are inclined to navigate because computing tools such as file managers are given to users for that. Users did not get better systems to find or file files or other documents in computing. In other words I wish to say that we are under developed. Navigating does not necessarily contribute to production. Productivity may say what it wants but it may not reach those who are actually more productive without using the navigation. So studies may not tell us what is more productive, such may only tell what is currently used within the subject of being productive. You mentioned 2 things, navigation and search. Since years I am integrating pieces in my computing that drives me into direction of neither navigating nor searching. Examples: - I read your email in Mutt. Maybe I remember something you wrote earlier but not quite well and I wish to find your previous email. I click ESC-v and I can view all your previous emails. In this sense I do not need to know your email address and where your emails are stored on my system. For this particular type of object "Emails of user Texas" neither I am searching, neither navigating. I do not spend time searching and I do not spend time navigating to that object. It is by one click or two all in front of my eyes. Underlying functionality is very simple. All emails of users can be automatically (by sieve) or semi-automatically by key press saved into personalized mailboxes ~/Maildir/person@example.com and by clicking ESC-v in Mutt, email address is extracted from the email I was reading and I new Mutt instance opens with all emails from ~/Maildir/person@example.com -- then after reading, I click q and I am back in your first email, the top level email in the inbox. I could as well make it more automated, I could answer all emails and finish with Mutt, and upon finishing all emails could be sorted in personalized email files. - example with files belonging to user, let us say hyperlinks or anything, any piece of information, I could just press F4 on email and I could access all information related to that user. I do not need to know the phone number and I cand send SMS or initiate the call, share the contact, send email or fax, see all pictures of this person, notes, tasks, and financial transactions. I neither navigate neither search there. Maybe better way to call this type of locating objects is relational accessing. Somebody may correct me. There is some object like contact named "Texas Cyber". If object has any relation to anything else, then anything else can be displayed and found right there. Instead of me searching, computer is searching. Instead of me navigating, computer is navigating. > This value is trivial with retrieval tasks such as a person's name, > which is why 10 Bins stores such names in a flat list of > directories, sorted alphabetically by last name. It is easy to > integrate an automated retrieval script with such a predictable > path. Take care of duplicates. When marketing contact database is growing fast, some times 1000 people per day or more. People have same names. Often one cannot even know what is first and what is last name. You may know it for your country, in other countries is not so. Then those people engage in a course on distance. They are sending me images and files as results of their course assignments. I have to file the files in proper folder. Because names are not always unique I better file it under unique IDs, and keep separate symlinks with names of people to such unique IDs whereby symlinks can be automatically updated. That alone makes things easily very simple at least for objects such as people because people's names are in the file system. Then simple `locate` command can be used to find Texas Cyber's files: #!/bin/bash locate -e -d /home/data1/protected/.locate.database -A -i $@ I think that switch -A helps in finding all of these: Texas Cy Cyber Tex or similar variations. But in general I would just click ESC-e and I would get your profile and access to all files because location by email address from an email document is pretty much decisive. If person is not there, person is then created in the database.