Is there any interest in a community guideline for storing external app configs?

Apps
1

Ideally, I'd like all of Joplin's configs to travel with Joplin's other data, including things like user styles and templates. They could live in a special 'config' notebook (optionally hidden in the Settings, for instance) and sync like any other notes.

But as long as there is no such thing available, would anyone else be interested in a community-defined guildeline as to where to store third-party configs?

For example, when writing the Ghoplin tool, I'd decided I'd simply create a note with a specific ID (00000000000031337000000000000001, so dibs on that one :smiley: ) so the tool can always easily find it (and the user can move it to any notebook or rename it in any way, without breaking anything.)

If there were multiple tools/scripts/apps/whatever that wanted to store some config data in Joplin, what do you think would be the best scheme? Everyone just picks a hard-coded note ID and uses it? Some specifically-named config folder every app could place notes into? Something else entirely?

It's also possible I'm just over-thinking this: if most apps are just bash scripts which only ever run on a single computer, or web-hosted apps like @foxmask's Jong with their own database, maybe it doesn't matter at all.

2

I don’t know enough to respond to your suggestion, but do have a technical question: Whenever I have to recover my notes from backup (import RAW) they are all assigned new id’s. How will you ensure your config note will keep its specific id?

3

As we don’t have anything to sync settings at the moment, I think your approach makes sense. I guess you’d need the API to create that note though? Another way could be to use a name that’s likely to be unique, like “config-ghoplin” and your app would look up for that note. That way the user can create it themselves directly from a client.

4

I wasn't even aware of that, so I'm not handling it in any way. TIL. Thanks. :smiley:

Thanks. I do need the API (very nice that it allows creation with a specific ID). Is that a bad thing, though? Wouldn't I need it to search for a note by name as well, wouldn't I? Maybe I've missed something?

True, but:

  • I think it's easier to use the API to just fetch a note by ID than to search for it.
  • Then I don't have to deal with weird edge cases, like what if there are more notes with that name? Perfectly valid within Joplin.
  • Also no problem when the user renames the note, be it on purpose or by accident.
  • And this may be just a preference, but as a user, I want my apps to do their maintenance by themselves. I want them to create and maintain their configs without me doing anything.

This last point is why, for example, Ghoplin has a command to 'write the Joplin API config to a file'. This literally is a text file that has the API token in it, no formatting at all, or anything. (It can have a second line with port number in it, but that's it.)
Is it trivial for the user to create it manually? Yes, absolutely. But then the user has to read what they're supposed to do (which is work :D), where to place the file and can just generally make mistakes. Reading 'run write-config <token>' is easier and less prone to user error, IMO.

5

Good point, especially about getting back the note. I don’t think there’s an API way to retrieve a note by title at the moment, so you would use the search engine but that might return other (less relevant) results too, so a bit of a mess to find your config in there.

In that case, the fixed ID as you’ve implemented it is the way to go, at least till we support this officially.

How does it work if two clients create the same config separately (which would have the same ID), then sync? I think the app should handle this fine by creating a conflict note, but worth checking if you haven’t already.

6

Ah, good point. I don’t have the conflict notebook displayed ATM and no way of making it show up. How does that behave? Will it cause any problems with the retrieval?
How should that be handled? Retrieve the config note, check its name, check for same in conflicts? Or will it have the same ID while there?

7

Let’s say in this scenario:

  • Client 1 creates config with ID1 and sync
  • Client 2 creates config with ID1 and sync

So Client 2 has a modified note with ID1 and gets another modified note with ID1 via sync. In that case, it will do the normal conflict handling:

  • Copy its local note to the Conflict directory. That will be a new note with ID2.
  • Overwrite note with ID1 with the content coming from sync.

So you’ll still have only one note with ID1, as the other in the conflict notebook is just a copy, which means your technique should still work. There’s no test units with hard-coded IDs like this though, so it might still be worth checking what it does exactly.

1 Like