Hi Guys:

I know what SQLite, org-roam and multi-user RDBMSes are and I use all of these things at various levels.  They are useful in many ways as you have pointed out and across time, we may consider optional integrations but one of the core design principles of Hyperbole is to work in all fairly current major versions of Emacs (today this is back to V27) on any display device and to not require any other external packages or C-compiled modules.  Now we will add optional package support where useful as we have done for Treemacs, ace-window and org-rifle but never require such things to use all of Hyperbole's base functionality.  We then know that all Emacs users can install Hyperbole and use it effectively without any external dependencies required, whether on a terminal or an old operating system or what have you.  This is part of the value of Emacs, common capabilities across a wide spectrum of computing environments.

If I had my druthers, Hyperbole would ship pre-compiled as well since in the past the byte-compiled code was forward-compatible across many major Emacs versions, but this no longer seems to be the case to me and the Emacs package system requires byte-compilation at installation time anyway, so we have a bit less of a 'turn-key' system than desired.

Although we build Hyperbole so it can be highly customized and programmed, we know that many people are just looking for ready to use productivity improving packages, many more than want to hack on a package.  Therefore, we focus our energies on delivering more and more value in that direction.

Org-roam is very capable for many people and we are not out to simply replicate it and slightly improve upon its behavior.  We want to provide a simpler, more contained solution for people who like and use HyRolo and want a similar solution for note taking.  Quick and easy-to-use where you can get in and out quickly, restoring your prior context rapidly, working with multiple file formats and usable wherever you use Emacs.

-- rsw

On Sat, Oct 8, 2022 at 1:03 AM Jean Louis <bugs@gnu.support> wrote:
* Hendursaga <hendursaga@aol.com> [2022-10-08 03:46]:
> Jean Louis <bugs@gnu.support> writes:
>
> > Of course it is so much better option than keeping stuff in text. All properties shall be in the database. SQLite is not a network database, thus it disables collaboration. It is better developing with PostgresSQL or MariaDB, or other network databases.
>
> Vanilla SQLite, that is. There are multiple[1] SQLite[2] addons[3] around[4] that add some sort of distributed layer to it, most being zero-cost (or at least low-cost) abstractions. Pretty cool, I'd say!
>
> ~ Hendursaga
>
> [1] https://dqlite.io/
> [2] https://litestream.io/
> [3] https://github.com/losfair/mvsqlite
> [4] https://github.com/rqlite/rqlite

Thanks, insightful, I have reviewed links. But none tells me that it
is truly network based database. Of course one may replicate files
through network and send data, that is not what is meant with network
database. One can make layers on top of it, but that does not make it
multi user or suitable for collaboration.

From:
https://www.sqlite.org/whentouse.html

,----
| Many concurrent writers? → choose client/server
|
| If many threads and/or processes need to write the database at the
| same instant (and they cannot queue up and take turns) then it is best
| to select a database engine that supports that capability, which
| always means a client/server database engine.
|
| SQLite only supports one writer at a time per database file. But in
| most cases, a write transaction only takes milliseconds and so
| multiple writers can simply take turns. SQLite will handle more write
| concurrency than many people suspect. Nevertheless, client/server
| database systems, because they have a long-running server process at
| hand to coordinate access, can usually handle far more write
| concurrency than SQLite ever will.
`----


--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/