Not using "exactly the main hamster machinery"

[GeraldJansen]

From @ederag's comment, it seems there is some concern about how hamster-tool interfaces with hamster and hamster databases. This issue is intended for further discussion of the concerns.

[GeraldJansen]

Background info: projecthamster/hamster#340.

[ederag]

First of all, I'm glad you created this tool, really useful.
Do however you please, it is and will be good, sincerely.

Let's hope the following makes sense, I'm real tired, and probably not very clear-minded.
Basically the - again slight - concern has two parts.

The first is a general one about forks. There are pros and cons.
The balance is even here, in my opinion, because it is very reassuring
to know that a simpler codebase exist and that the database will always be readable
one way or the other.
The risk to split the user base is quite small at the moment,
since the main project "official" is very alive.
This leads to the first slight concern: what if your code starts to have different constraints
for some reason (e.g. no dbus).
Either we will both want to consider the whole user base
(both forks as a whole), and design decisions may become tougher.
Or we split due to different design decisions, and we lose the advantage of robustness.
The "same machinery part" also refers to this: we may get irrelevant bug reports
because they are posted to the wrong codebase. Users won't be able to know.
And confusion tend to repel users.
But richness is good, because maybe you'll have found another way and share it back,
as you already do.
Well, you get the idea: in a perfect world we all work on the same codebase in harmony,
but the current status is fine with me, I understand and see some advantages, really !
Let's hope my shortcomings don't drive you out. You are very important for hamster.

The second slight concern is the reason I raised this when I mentioned yours in the other thread
as an example of a successful "external" companion to hamster that was not using D-Bus.
A central server with D-Bus is there to prevent race conditions.
What if the hamster server is on, with another external tool (e.g. stopping on screensaver),
and accesses the database when a merge is on ?
I do not know your code well enough, and there are ways to mitigate that besides D-Bus,
so this point as well is just a slight concern.

Hope that clarifies. No need to worry too much, IMO.
If you feel that anything was not appropriate, please let me know.

Edit: TL;DR
It uses a fork, and it uses a non-standard (not client.py) way to access the db.
No big deal, it's good overall

[GeraldJansen]

The main reasons I developed this as a separate tool, outside of hamster, were: 1) There was very little chance of getting a PR for a new feature into Hamster accepted at the time because you were clearly struggling just to deal with bugs and consolidation of important infrastructure. 2) I didn't know how to access more than one database from within Hamster (one for the export and one for the load/merge), given the complications of hamster-server/dbus. I think it would be much better if the load and merge functionality could be incorporated into Hamster under the CLI.

[ederag]

1. All still true, slowly relaxing.
2. Fully understood now.
   We need at least read-only access to secondary databases, without dbus. Opened #570.

I think it would be much better if the load and merge functionality could be incorporated into Hamster under the CLI.

This is an important functionality, but it is a relief to delegate this responsibility 🙂. We'll see.
Another advantage to keep things external is that if the rewrite resumes,
the same tools will be usable without modifications.

[GeraldJansen]

Closing because no further discussion is forseen.