Re: Org and Hyperbole

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4298 bytes --]

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/
>
>

[-- Attachment #2: Type: text/html, Size: 6099 bytes --]