[FAQ] - Auto Upload to Online Service

[foldynl]

Q: Is it possible to implement online upload (synchronization) to online services?

A: Initially, I thought it was an easy task, but through a step-by-step analysis of the problem, I have concluded that this feature will not be implemented at the moment.

The following areas need to be addressed for online upload to be useful:

• Insert QSO
• Update QSO
• Delete QSO
• Behavior during offline mode, switching to online mode (only selected services are online and various combinations)

Except for point 4, when QLog should handle it, the implementation of points 1-3 depends on the service. Unfortunately, not all services have these basic operations implemented.

According to my research and public information, the situation is as follows:

• Clublog - all operations are implemented
• HRDLog - all operations are implemented
• QRZ - all operations are implemented. Delete requires LOGID, a QSO ID assigned during the Insert operation. QLog does not have such LOGID for imported QSOs. Obtaining this would require QLog to query all imported QSOs, a process that QRZ administrators might not approve of due to potential thousands of QSO queries after import. Querying the QSO before the delete operation is possible but time-consuming. What should happen if this operation is unsuccessful? Should QLog prevent deletion or accept the risk of desynchronization?
• Eqsl - insert and update are implemented, but delete is not implemented
• LoTW - all is controlled by an external application, delete is not possible, and update needs a special exception.

In general, question is what should QLog do if error is detected during update/delete. Should block the operation in Qlog, should store the operation for later processing, how long should store it?

There can be many situations where the online/offline log can become desynchronized. What should QLog do in such cases? There are also more questions, unfortunately without answers.

While there is a possibility to implement online upload for selected services, from the user's perspective, it would be confusing to determine which service the online upload applies to. Another limitation is that, for example, LoTW is not an online upload service; it is a batch-processing service.

Based on all the information above, it appears that online upload can only be practically implemented for ClubLog and HRDLog. Unfortunately, this is not acceptable from my standpoint.

Am I wrong? Should I change my mind and implement it only for selected services? Will it be understandable for users?

[M0OPK]

I'm aware this is an almost 3 year old post. But, I just installed QLog last night and was thinking about this. Because I came from a logger that did real time upload and yes it would stick if there was a problem and error right there and I agree that's not the ideal way.

However could there not be a second way that might work something like this:

• Thread runs in background and will poll a queue of logs awaiting upload. This is to prevent locking up the main process if there's a service problem.
• Attempts to upload as soon as qso complete but will not hold up main program if service(s) are slow/down.
• If there is a failure it doesn't need to show an error. If people have upload confirmed on their log columns they will see it didn't go. Otherwise on startup if immediate log is set for a service, a popup could show pointing out there are non uploaded log entries and allowing for the manual process. That could then show errors (like log into that needs fixing, or might go through if it was a service problem).

I'm not sure there needs to be any extra storage. Because the log already stores whether it uploaded to qrz/eqsl/lotw etc, when you invoke the upload process. So, it could try to auto upload right away, and if not just not flag the entry and inform user next app start and it would then force the use of the current process of uploading anything missing.

Anyway, just a few thoughts I had on the matter.

[foldynl]

@M0OPK Even after three years, the arguments mentioned above are still valid. This is not really about blocking the main thread; the main concern is that the data may become out of sync, for example after a DELETE operation or, in some cases, even an UPDATE.

The current model assumes that once the operators are satisfied that everything is correct, they upload their QSOs to the server. The only exception is ClubLog, for which online uploading has already been implemented.

I understand that many operators would like this functionality, but its possible consequences also need to be considered carefully. This is simply the approach QLog currently follows. If this workflow does not suit someone’s needs, fortunately there are other logging applications that may provide exactly the behaviour they are looking for.

[M0OPK]

@foldynl Yeah I totally understand the point about updating after the fact. I've used other logging software that uploads immediately and needed to adjust things after the upload. Generally in that case it's rare because I'd hold the log open until the QSO is over and in 90% of cases the values are all correct. In the odd case it isn't, yeah I'd need to edit manually.

But, my thought here is. That QRZ at least when I imported my log went off and edited everything in place. Or it deleted/re-entered all the log data, which is in real terms the same net result. Either way from my view all the log entries were updated.

Also on the QSO in the log is the upload status. Was there success in uploading the log? So for QRZ, what would be the bad scenario? Because at the moment the normal upload process can update (or delete/update entries). If there is an error/timeout I suspect that process also wouldn't mark the log as uploaded and would try again next time on the manual upload.

So, could this not also work for QRZ at least. Where it would try to upload when the log is saved. If there is success it would mark the local log entry as uploaded. If there is an edit needed later the upload process could upload (as it already does) the changes made to the log, e.g. it marks it as not uploaded, or a new status of edited meaning it needs uploading the changes. If there is an error uploading right away it would be marked as not uploaded and picked up in the next manual upload anyway. It just seemed to me the pieces were all already there. Just not connected for this potential option.

Anyway it's just a thought. It's a minor thing in the overall scheme.