Re: One vs many directories

[Jean Louis <bugs@gnu.support>]

* Ihor Radchenko <yantar92@gmail.com> [2020-12-02 05:53]:
> 
> Jean Louis <bugs@gnu.support> writes:
> > hypothes.is is free software that may be installed locally.
> >
> > https://github.com/hypothesis
> 
> Thanks. You inspired me to try installing it locally again.
> 
> The main problem with hypothesis is that it is designed to be deployed
> to a server and not to a local machine. Thus, the instructions imply
> some knowledge of server configuration and skip several important steps,
> which were not obvious for me without spending quite a significant time
> googling for various issues during and after the installation.
> 
> Anyway, I finally managed to get it working with my local setup. Next
> step is Emacs integration...

That is great to hear. I wonder how it can be integrated with Emacs as
it is all Javascript based.

Here is the Org version of: 

Technology Template Project OHS Framework as Org file
http://ix.io/2GdW

I suggest when making tools for Emacs that developer of the tool looks
into the template for open hyperdocument systems that system are
developed that they benefit most people.

- "Open" :: implies vendor-independent access to the hyperdocuments
  within and across work groups, platforms, and applications.

If such system is developed with the database backing and generic
hyperlinks then database is vendor-independent (mostly, but it is
still PostgreSQL, but could be any other because it is SQL), then it
can work for any kind of groups, it can be accessed from various
platforms by using Emacs, but it can also be accessed by browser, but
also through other programming languages would such program be
re-written.

For Org, to be open hyperdocument system it would mean to spread it
onto other editors such as Vim where basic Org mode already exists and
other editors, and applications, such as those on Android like Orgzly
that supports Org. But all that does not make Org yet open especially
in relation to hyperlinks.

Hyperlinks should be dynamic not static and centrally managed not user
managed to be work over various platforms, applications, for various
groups.

Using hyperlinks like:

file:///something/pdf:page 1

Is not portable for many. Such hyperlink should be dynamic, which
means if user accesses the database from remote host such could not
access such hyperlink. It would need to convert to ssh:// or scp:// or
ftp:// or https:// hyperlink or something else.

These types of hyperlinks would be better:

user@hostname.com:PDF:Page:1
or
user@hostname.com:PDF:Query:Title
or
user@hostname.com:PDF:Selection:1,2,3,4

but then again they are not enough generic. I am now making hyperlinks
whihc are very generic, they can just designate the node number and
server from the server list, could be something like:

hyperscope:show:1:2 - to get the human designation of the hyperlink,
                     what it is really.
		     
hyperscope:activate:1:2 - to go to server 1, node 2 and activate
                          hyperlink. If I am on local file, Dired
                          would open, but if user is accessing it
                          remotely the hyperdocument would open in
                          different way. That is what I mean with
                          dynamic hyperlinks.
			  
hyperscope:email:1:2: - it would send it by email to the user. Because
                        system identifies users with their usernames
                        and other attributes

hyperscope:email:1:2:user@example.com - it would send hyperdocument to
                                        other user if there are enough
                                        permissions

In that sense of having generic hyperlinks one should also make
annotations. If I make annotation on Emacs than such should be
translatable to let us say Hypothes.is but if not with that tool,
hyperlink for annotation could open on Emacs with Xpdf or Evince
reader on specific page number while showing annotation in Emacs.

Systems should work equally well in any browser because of their
generic nature. Hypothes.is is now working on browsers, which is for
me very limiting.

They should be liberated from browsers as well. That means that API
should be there that allows access through any interface.