Re: Designing people and organization management for Emacs

[Christopher Dimech]

> Sent: Friday, December 04, 2020 at 7:23 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Designing people and organization management for Emacs
>
> * Christopher Dimech <dimech@gmx.com> [2020-12-04 21:06]:
> > > When preparing Emacs package let us say for people's contact
> > > management then users do not need to think much of the underlying
> > > database table design. They think of people's names, birthdate,
> > > address, and contact information.
> > >
> > > Programmers need to know how to make functions or do SQL queries.
> >
> > Would things be general enough with your plan?  For instance,
> > settings fields and naming them, on which the queries would run.
>
> That is what I do now mostly. I can create any table and then add,
> edit, delete records. But it is not perfect, it needs work.

That,s been my concern.  But one will have to see.

> There will be also simpler version to create your own tables similar
> like a wizard. Then users can add, edit, delete records or search
> them.

You are getting to something then.  I'm pleased to hear that.

> > Can test it out and ask others using it for their work.  Have some contacts
> > at the Osservatorio Vesuviano, Naples (Italy).
>
> Database may be used by any language on any operating system while
> Emacs Lisp is for Emacs only and there is  web browser interface as
> well.

They got to use emacs, of course.

> I have many tables and views defined and Hyperscope dynamic knowledge
> repository development is simplifying some other tables.
>
> Node in Hyperscope can be anything, for example WWW hyperlink that is
> annotated or has description. It can be note or action like a task. By
> using types one can then define anything. In that sense the table
> "notes" is dropped and replaced with hyperdocument that may be "note",
> table "tasks" is dropped and replaced with hyperdocument that may be
> "action". Based on the principle of types, then the table "people"
> should have pretty extensible design or model that will stand the
> future in the sense that users may define their own types for table
> columns.

That's the real beef!

> Example would be to let user define type of contact to be "Fediverse"
> with the value @somebody@example.com and then user can make function
> how to communicate to such contact.

Ok.  I'm excited about this.