Closed myzinsky closed 4 years ago
Hi Matthias,
eQSL-confirmation is a two-way-process we already have in cloudlog. The process looks like following:
Step 2 and 3 requires your login-data in admin-settings/profile-settings.
73 de Kim DG9VH
Information on eQSL confirmations is shown within the logbook page and popups, within the next few weeks you'll be able to filter QSOs based on those fields
Okay, I will try that out. And displaying the eQSL card would that work too?
Hi, actually only the confirmation itself is visualized:
Do you have any information about fetching the QSL-card's image from eqsl.cc? Then we can integrate it into the cloudlog (maybe as a mouse-over-layer or similar...).
Yes the process is rather simple: http://www.eqsl.cc/qslcard/GeteQSL.txt
If you point me to the right place, I could also implement it and open a PR.
Looks like http://www.eqsl.cc/qslcard/GeteQSL.txt guess best solution is to grab the image and cache it locally.
I just tested it, it works
@myzinsky well, feel free to create a fork and try it out :-)
@magicbug maybe it would be a way to fetch the images via cronjob-script once a day based on eqsl-received = Y and (new database field) eqsl-image-cached = N to only fetch those cards from web, that are not cached previously...
What we should consider is how much storage do we need for the images? how much kB would such an image consume on disk-space?
I think the images are really small (its png ~300kB and could be converted to jpeg on the fly) and IMHO disk space is no constraint anymore, nowadays ;-)
The images could be stored either on disk, or in the database. What would you prefer?
The idea of fetching eQSL data automatically via cronjob would be also nice. Another idea could be to show if an OM does not have eQSL (the arrows could be greyed out). And then it's directly clear that a paper QSL should be sent.
Ok - in real I never was interested in the image itself g when doing eqsl, for me the flags (confirmed) where relevant :-)
The real question is, what would be secure and performing - storing the image-data within a blob or storing it within the file-system...
Maybe (after implementing a proof of concept) we can offer both ways (configurable via /config/cloudlog.php)?
Definitely not don't advise storing images in the database as blobs far to much overhead for little reward when it is easy enough to keep it on the file system.
I'd suggest images are grabbed when logs pulled down from eQSL for confirmations although a function to grab them for example if the scripts already been run.
If to store the images in /assets/images/eqsl/ and name the image the primary key value of the QSO record it will make it easy.
But I agree, functions for displaying need to be optional, a lot of people won't be interested in seeing the cards.
I think, this could be a good thing for @myzinsky to get familiar with cloudlog and it's structures of files etc. :-) a way of practise :-)
A possibility to place the "show QSL-Card"-link could be the drop-down list at right, where we have edit, mark received as ... and delete...
Yes fairly straight forward, Codeigniter has plenty libraries to make this rather easy :) which can be found at https://codeigniter.com/user_guide/general/index.html
okay I will give it a try :)
There is already a problem:
Graphics for eQSLs are generated on-the-fly, i.e. at the time they are requested. This is a processor-intensive task that has the potential to slow down the entire system. PLEASE limit your use of the GeteQSL.cfm program to individual eQSLs at a speed of SLOWER THAN 6 PER MINUTE.
So this is somehow annoying. As first step I would then only generate a button to show the QSL. Later on, we should consider to have a cronjob or thread which downloads with a low pace all the images and caches them. But as a pragmatic solution, the download link should also be fine.
You should nevertheless consider about caching the fetched images for viewing them again later without requesting them again.
yes, this will be the next step then :) ... first I will upload a PR with an uncached implementation. #348
OK left some comments on the PR so, for now, we shall move the discussion to there :)
Just a side remark. On eQSL.cc some users where a card was sent out are marked as grey, meaning that they are not longer doing eQSL for example. It would be nice to mark this as a grey arrow. Do you think that this Information can be retrieved from eQSL?
I'm not sure if its returned or not, however I'd say we keep to marking eQSLs as the following
Y - Yes (as in confirmed) N - No (Incoming not received) R - Requested (QSOs uploaded to eQSL but hasn't been confirmed) I - Ignore/Invalid
I've added the ability to show the card it goes directly to eQSL, currently isn't downloading the card for storage. that needs to be added and probably an extra table in the database just to hold the qso id and the eqsl image name..
After playing with the interface, worth pointing out it would be impossible to download images in batch as the rate-limiting is fairly heavy.
Exactly, that was also the reason why i had no time to integrate this. There should be a kind of background job that downloads them with a certain delay in between.
I just tested it, somehow ALL QSOs are shown with a received eQSL card. This is somehow not correct :-/
Also when I click on the arrow, the QSL card is not shown...
Now sorted, in the latest commit, fixed arrows always being green (testing bug), added a new table eqsl_images added a folder images/eqsl_card_images which needs write access
Now it will check database to see if it has the image, if not it will go grab it.
Note not background downloading them, if you can get an image on click you will be fine else errors.
Should be fine for standard usage
Marking this as done its working perfectly on my live copies!
I confirm! It works!
Thank you so much, 73
Display the received eQSLs. Since the eQSL Website has a cruel interface it would also be nice if all the confirmation could also happen in cloudlog.