Re: exported contacts problem

[Jean Louis <bugs@gnu.support>]

* Eric Abrahamsen <eric@ericabrahamsen.net> [2019-08-03 17:39]:
> No, and I think it would fall apart under your workload. But I would
> like to make it better, and gradually get it closer to supporting the
> sort of thing you're doing.

I have started some teaching lessons in how to create personal
information management, but it will take time until it becomes
ready. I wish GNU Emacs would have more of such applications
developed, including invoicing people, accounting and similar.

> Yes, that's on my (mid-length) list of to do: a vcard parsing library
> that just turns vcards into a couple pre-defined formats, or lets you
> register your own consumption functions.

That is really missing, as Androids are providing contact management
export in VCF format. The NextCloud contact management has it too. It
became some kind of a standard. Even it is not as good for exchange. 

> I'm also not fond of vcard, but I *am* fond of carddav, and having my
> contacts synced to my phone, and shared with co-workers, etc. Otherwise
> I probably wouldn't bother.

I was looking on Wikipedia, that is basically protocol to exchange the
vCards if I understand well. Exactly, for syncing it is necessary.

> EBDB now provides for a sort of poor-man's relational database, with
> multiple roles and relations, linking people to people and people to
> organizations. But it's still limited and kind of awkward.

That is true.

I have started long ago with PostgreSQL and it works well, and it is
extensible.

What I think it is good is to give to people possibility to extend the
personal information management without limitations. As such are the
SQL databases.

I have been using Gedafe[1] for long time. It is Generic Database
Frontend and it works over web. But for my fast writing and needs it
is not enough fast. Also not developed for long time. But imagine, you
create the table and the interface gives you search, to add, delete,
modify records and with some efforts to make custom reports. Isn't
that nice?

In that sense I have made few functions to read the database tables
and basically edit any field there is through Emasc Lisp and helm.

Now imagine if you make ebdb so that it is based on a database and
that people can freely add a new database related to basic skeleton,
and that all tables can be used and inserted.

Then we have all kinds of opportunities:

EXAMPLE A:
==========
1. Maybe somebody is managing lands, like real estate, he could make
   real estate database tables, and relate it to people in the contact
   address book. Right? Isn't that why we are keeping the address
   books, because all of the people belong to some kind of groups, be
   it family, or enemies, sibblins, customers, it could be donors, it
   could be potential leads, travelers we meet in hotels worldwide. It
   could be real estate owners, right? Somebody needs familiar
   interface to manage entries related to real estate related to
   contacts. It requires "relational" database.

2. Then Org mode could be used to link directly to the person in the
   database, and link to the report about the house from the real
   estate database. It results with real estate report in the Org
   document with pictures, that can be printed, distributed, glued on
   the display, and similar.

3. Now imagine some will have 300 or 1000 properties to list that way,
   it becomes breeze to speed up such cycles.

EXAMPLE B:
==========
1. Imagine Italian manufacturer selling Venetian masks. Customers are
   from all over the world. He could create table about "Venetian
   Masks" and relate it to contacts and organizations. Generic
   functions to edit such table, modify entries, add new entries could
   be made in Emacs Lisp. It becomes inventory management.

Any of those tables in the database are almost always related to some
people.

And we keep having separate packages for this and that, instead of
using databases more for the relational organization of information.

Jean

Footnotes:
[1]  https://gedafe.github.io/index.en.html