* David Masterson <dsmaster...@gmail.com> [2022-10-10 19:55]: > Jean Louis <bugs@gnu.support> writes: > > > * Robert Weiner <r...@gnu.org> [2022-10-09 00:06]: > >> 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. > > The issue here is distribution. Databases tend to be centralized and > heavy weight.
What does it mean centralized in this context? Majority of Relational databases that I know have built-in collaboration features so that people may access them from any part of the world; many have replication features. I am not sure if "centralization" even fit into the context. > Here, we're simply looking for a standard way to capture an image > (or more) with a task/note and tranport it back to your main Org > file (a la Org Mobile or ...). Org is lightweight in this area > which is good and bad. Regarding sizes: ================ $ du -skh .emacs.d/elpa/org-20201216/ 11M .emacs.d/elpa/org-20201216/ Database like : sqlite3 Installed Size : 7.55 MiB Reference: Relational database - Wikipedia: https://en.wikipedia.org/wiki/Relational_database You have misconception of what is lightweight or what is not or what is difficult, I guess it comes simply from not trying it out. There is no "standard" way of taking notes, especially not in Org, neither in Emacs environment, or generally for people. Creating tables is pretty, new Emacs development has got SQLite built in: (defun my-create-table-notes () (rcd-sqlite "CREATE TABLE notes ( notes_id INTEGER NOT NULL PRIMARY KEY, notes_datecreated TEXT NOT NULL DEFAULT (datetime()), notes_datemodified TEXT NOT NULL DEFAULT (datetime()), notes_name TEXT NOT NULL DEFAULT '>>>EDIT<<<', notes_type INTEGER NOT NULL REFERENCES notetypes DEFAULT 1, notes_text TEXT)" rcd-people-sqlite-db)) Making a function to add a note is easy: (defun rcd-db-table-sqlite-notes-insert-new-row () "Add new note." (interactive) (let* ((name (read-string "Note name: ")) (prompt (format "Description about `%s': " name)) (note (string-edit "" "" 'ignore)) (sql (format "INSERT INTO notes (notes_name, notes_text) VALUES (%s, %s) RETURNING notes_id" (rcd-sqlite-escape-string name) (rcd-sqlite-escape-string note))) (id (rcd-sqlite-first sql rcd-people-sqlite-db))) id)) (defalias 'notes-add 'rcd-db-table-sqlite-notes-insert-new-row) Viewing, listing, getting it back, making agendas, all that works with so much less coding, works, less errors, and more speed. Exporting to Org is easy: (insert "\n\n" (rcd-sqlite-first "SELECT group_concat('** ' || notes_name || '\n\n' || notes_text,'\n\n') FROM notes ORDER BY notes_datecreated" rcd-people-sqlite-db)) ** Something My note #1 ** My other heading My note #2 ** Something I knew before My note #3 1 As Org users already wish and want to have structured properties, tags, headings, links, tables, then it is right way to think that with Emacs 29 and SQLite built-in, many things will become easier. Let us say keeping list of information such as accounting, expenses, invoices, tasks, notes, etc. for any type of information database has no ambiguity about structured information, errors are minimized, programming efforts minimized. Pitfall would be that we would not have much discussion like now, as with less bugs, there is less talk. Imagine Org heading like this: * My heading :PROPERTIES: :DB-ENTRY: :my-remote-host:my-database:my-org-table:id:1234 :END: Then imagine a pre-processor before saving the file or a hook for saving Org file. Each time that file is saved, the heading entry could be updated on remote host, database, table with ID 1234. It could be distributed, assigned, sent, easier shared, because data is better estructured, Or it could be updated in a local database. Or it could be used to keep any kind information related to Org heading. That is glue between the text file and well structured and non ambiguous database. If Org has mechanism to parse links in a file, a save hook could parse them and store in database table for backlinks. Sometimes URL change, imagine Org link like: dbid:1234 that remains immutable and which fetches the underlying dynamically updated URL. If some Org headings are stored in the database, they may be updated in Org file automatically. Linking to Org headings could become so much more deterministic, as one would link to unique ID in the database, no matter how heading is named or where is it stored. Collaboration door is open with networked databases. Concurrent access to Org headings, links, contacts, becomes possible. Wide range of options. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/