search

foldynl / QLog

Amateur radio logbook software
GNU General Public License v3.0
114 stars 16 forks source link

Question about future function - synchronisation of QLOG #255

Open michalsiman opened 8 months ago

michalsiman commented 8 months ago

Question about synchro, if this is in plan. QLOG is perfect, very nice and respect for somebody who make an app like this - usefull, multiplatform, working - that is great. What i would like ask is synchronisation, i have one computer home, on computer for portable, i would like have one log all the time. I know more people, who like synchronisation - and synchronisation mean backup as well. I know it is not easy. Can be used synchronisation by gdrive or other cloud files space / backuping and synchronisation can be solved together. Just if you thinking about, maybe for future? Thank you for answer. And again - thanks for your perfect work, respect!

foldynl commented 8 months ago

This question can be answered in a short or a long way.

The short answer is: YES, I've been thinking about something like this for a very long time.

Long answer: As you mentioned, everyone means something different by the term synchronization. Therefore, let me describe, as I mean it. I have 2 or more computers with QLog connected/disconnected from the Internet. If I make a QSO change on one connected computer, the change should be propagated to all connected computers. And it will be advertised to those what are not connected while they are connected to the site. That's pretty clear. The problem starts in these situations.

1) You make a QSO change on a connected computer and then make a change on a computer not connected to the Internet in the same QSO and in the same parameter but to a different value. A conflict arises that must somehow be detected and resolved.

2) Synchronization also means that when you import a QSL card image to one QLog instance, you expect this QSL card to be synchronized as well. Is it necessary to resolve the binary data conflict (which QSL will import in case of QSL file name conflict. Does it mean a different file or picture replacement?

I am not saying that these are unsolvable problems, but tuning this system will not be easy task. My idea is more complex because I want to avoid a centralized element and make it peer-to-peer. Most users don't want to install additional software for synchronization, so all logic must be inside QLog.

The whole thing can become simpler if we assume that it will never be possible to work on two instances of QLog at the same time, so you won't have to resolve conflicts. But honestly, it's not synchronization, but simple export/import. And import/export is already present in QLog.

So if you only want to have the same QSOs on two computers, then at the moment it is only possible to do it via export/import. The problem is only with the QSL cards, which are not transferred with the export.

In general, QLog lacks migration of the entire log (QSO, settings, QSL Cards, etc.) to other computer/platform. It is necessary to solve this, because a situation may arise when you migrate to another computer / platform, and you want to transfer all settings, QSO and QSL cards with you. And that's exactly what I'm doing now - cross-platform transfer of all QLog things. Once this is resolved, you can use it for your "synchronization" between multiple computers, only in case you don't change QSOs on multiple computers at the same time.

Allow me the last couple of sentences. I would like to see full peer-to-peer offline/online sync in QLog. If anyone has any ideas, the ideas are always welcome. I don't expect PR, but brainstorming would be good. Maybe I see it too complicated.

michalsiman commented 8 months ago

I understand, it's a really hard decision. For me personally, I would set up one machine as MASTER and another one as SLAVE and only in MASTER would do things like uploading to a clublog, qrz, eqsl and so on and only the QSO itself would go from (and to) SLAVE. So in SLAVE I would only have a QSO (i.e. a clean diary), which is nice that in SLAVE somewhere on the portable I could see who I did QSO with, but other things like QSL and synchronization with cloud services would just be on the MASTER machine. For me this would be the most efficient and effective and would meet (in my opinion) 90 percent of the synchronization requirements.

We're talking about people who do things like WWFF, POTA, SOTA, GMA - some of them go with a computer. Or people who go to chat rooms or just to some club workplaces and broadcast there under their brand name.

Or you could talk about a club diary that is managed by one operator, but the other X could contribute to it in this way, they would just synchronize the connections themselves between the MASTER machine and the SLAVE machine. Resp. between the MASTER machine and an unlimited number of SLAVEs. It would be an interesting function, which is not so common.

But I understand, it's difficult to execute (implement) but mainly to decide how it will work.

Maybe for a start just to do some option to run import/export from the command line e.g. Then I could make a shortcut on one machine that will perform import and then run QLOG and vice versa after the end perform export ... I would actually do a sort of synchronization myself and easily.

The possibilities are dozens ....

foldynl commented 8 months ago

I understand, it's a really hard decision. For me personally, I would set up one machine as MASTER and another one as SLAVE and only in MASTER would do things like uploading to a clublog, qrz, eqsl and so on and only the QSO itself would go from (and to) SLAVE. So in SLAVE I would only have a QSO (i.e. a clean diary), which is nice that in SLAVE somewhere on the portable I could see who I did QSO with, but other things like QSL and synchronization with cloud services would just be on the MASTER machine. For me this would be the most efficient and effective and would meet (in my opinion) 90 percent of the synchronization requirements.

if we talk about synchronization, then it is not possible to talk about Master-Slave architecture. In a fully synchronized environment, it doesn't matter where you did the given action, everything should be synchronized to the rest of instances. That's what I mean by synchronization - in the other words, to have an active-active cluster architecture.

It seems to me that what you are talking about is the possibility of uploading differences from one instance to another (export/import).

We're talking about people who do things like WWFF, POTA, SOTA, GMA - some of them go with a computer. Or people who go to chat rooms or just to some club workplaces and broadcast there under their brand name.

Or you could talk about a club diary that is managed by one operator, but the other X could contribute to it in this way, they would just synchronize the connections themselves between the MASTER machine and the SLAVE machine. Resp. between the MASTER machine and an unlimited number of SLAVEs. It would be an interesting function, which is not so common.

But I understand, it's difficult to execute (implement) but mainly to decide how it will work.

I understand all the written examples, but all the examples lead to an environment that must be synchronized on both sides, especially during club activities.

Maybe for a start just to do some option to run import/export from the command line e.g. Then I could make a shortcut on one machine that will perform import and then run QLOG and vice versa after the end perform export ... I would actually do a sort of synchronization myself and easily.

command line approach is usable on Linux and MacOS. Windows (partially MacOS) users don't want to use the command line parameters.

The possibilities are dozens ....

Yes. it is only necessary to choose the right one so that it can be used on all platforms, then it is very simple, then it does not break other things in QLog, then it does not break the Online services, then it is intuitive, then it does not depend on something that cannot be used in open-source(GPL) world, and mainly to be able to implement it in a reasonable amount of time.

As I wrote, I have something planned. It will be about the import/export all QLog things. You will be able to export one file that will contain everything that QLog needs to run. And then you can use this file on different computers. Unfortunately, there are also many challenges, because, for example, it is necessary to protect passwords, to be multiplatform and other things.

To be honest, at this moment I don't know whether it will be usable or not. It may be the case, as with many previous ideas, that it will be unusable. We will see later.