When you change the graphic or update the text on your own eQSL card, will it take effect only for eQSLs sent from that point forward, or will it change on all eQSLs sent from your account it the past also?

73,
Bill - WA5PB

---

WA5PB William Allen

This thread triggered a question I wanted to ask... What is the possibility of having several graphics available for my eQSL design? In other words, a recipient could select say one of four designs when they want to print my card?

Right now I have a winter scene for my card. What are my options for saving this design and creating a summer scene.

My thought is 4 different designs to choose from would be adequate.

73 de Bob - K0RC

---

73 de Bob - K0RC

Bob, K0RC, I totally agree with you, same goes here, winter cards in the winter with my snowmobile, summer with the harley, etc... if we change it before he received it... no good.

Not a good design, when a SQL card is sent... it should be sent... in this system, it's not "sent" until it's "read"... weird... wait to see a few years down the road before retreiving them, and you get the one of the minute... I do not think it's good.

If you contacted me 3 times in the last 3 years and I get you a QSL each time (different, I change once in a while) and you come and get them now, you'll have all the same... no, I don't like that....

What do you think all, and the system admin?

Thanks.

73, Sylvain VE2FET
PS Trying to make things better ;-)

---

VE2FET Sylvain Faust

Unfortunately, this answer is *not* correct. When you change your eQSL graphic it immediately takes affect for all QSL's you have sent in the past as well as those you will send in the future. Each account can have only one QSL graphic so when you replace it the old one is removed from the system.

---

73, Rich - W3ZJ

Currently each account can have only one QSL graphic and because of the additional space it would require to store multiple graphics for each account, I doubt very much that this will change.

---

73, Rich - W3ZJ

Rich:

Cut me some slack, OM. What part of the answer I offered "is not correct" ?

73, de ~ Vince ~

---

WA2RSX 73 de OPR: VINCE

Indeed, when a user makes a revision to his eQSL card graphic design, the previous design data is overwritten with new data. To form a composite eQSL card graphic, that is ultimately viewable on screen and available for printing on a local printer, a process of overlaying the following elements is implemented by the eQSL software:

1. the user selectable JPEG/GIF image that is used as the background layer within the composite graphic. In general, those images are contained within a library of available images and are selectable in accordance with rules defined by the users’ present membership rank, e.g., REGULAR, BRONZE, SILVER, GOLD. See http://www.eqsl.cc/qslcard/ChooseCardStyle.cfm .

2. the textual data that the user may enter under the heading of “Printed on eQSLs” within the users account profile, see http://www.eqsl.cc/qslcard/EditProfile.cfm .

3. the eQSL.cc recognized ADIF QSO record data fields that are store within an area of the eQSL system database, which is sometimes conceptualized as the user's OUTBOX. See also http://www.eqsl.cc/qslcard/ADIFContentSpecs.cfm .

Whenever my QSO partner chooses to review my eQSL graphic card that confirms our QSO, the existing graphic design data and only the data existing during the time of review is useable as the source for "on the fly generation" or population of the viewable composite eQSL graphic card.

"all QSL's you have sent in the past as well as those you will send in the future" misleads users who might interpret this to mean that the eQSL graphic cards are individually stored on the system. That would be an incorrect conclusion, since the composite graphic is not stored on the system. However, the individual elements identified above are stored within the appropriate areas on the system.

73, de ~ Vince ~
WA2RSX

---

WA2RSX 73 de OPR: VINCE

It's time to move forward. Storage space is not that big a deal anymore. Just look at the proliferation of "Myspace" and similar graphic oriented blogs on the internet.

If I wanted to "cheat" the system, I suppose I could setup multiple accounts with, as you pointed out, a separate QSL design for each account. But I would rather put the feature request on the table for serious consideration and not simply dismissed.

I'll look to see if there's a feature request forum where this idea belongs.

73 de Bob - K0RC

---

73 de Bob - K0RC

Hi Robert,

I'm not sure I know why anyone would want more than one eQSL design per account but let's assume that such a feature was implemented.

1) What criteria would you use to indicate which design you want to use for a specific QSO?

2) If you upload your log how would you specify the card design in your ADIF file. There is currently no defined ADIF field for that in the ADIF 2.0 specification.

3) Is there a log program currently available that provides a feature that would allow you to specify a QSL design in your log?

---

73, Rich - W3ZJ

Hey Rich,

I was thinking along the lines of implementing something very simple.

For example, right now I can click on the "Display" button and the QSL for the QSO comes up automatically for preview and printing. This is where an intermediate window that displays the thumbnails of 4 QSL designs I have created would be displayed. As a QSL "retriever", I would decide which one I liked, clicked on it, and this is the design that would print. If I wanted to print a different design, I could come back and click on a different image.

So for your number 1, my thought was to leave the design decision up to the QSL retriever. The software would probably need a "Default" setting in case there are automated printing routines I am not aware of.

For your number 2, I don't see ADIF being involved in this process. But maybe I'm missing something here.

And number 3, I don't know, but again at the level of implementation I was thinking about this would not be an issue.

Of course there would need to be some programming work done on the user QSL card creation routine so you could design and save multiple cards.

Thanks for listening and passing along my thoughts. I see there is a "features" forum, but I'll let this rest here for the time being.

73 de Bob - K0RC

---

73 de Bob - K0RC

Ahh yes having the recipient choose between a number of different images is an idea that never even occurred to me and it certainly does not present the problems I mentioned.

Anyone else have an interest in that?

---

73, Rich - W3ZJ

My whole issue like I've posted on May 13 is the fact that the information/data is "floating/live". Meaning if I send a QSL now and change/update my design next week because I have a new BEAM or RIG, the guys to who I sent the QSL last year will see the new QSL design, graphics, with the new information NOT that does not apply to them...

When a QSL is sent... it's sent. No way on modifying comitted data... maybe it's my personal background talking now but that's the way information system and transactional system works.... like it should be, and not like the hardware/software permits... this is system design upside down. There should be requirements base on the way we do process QSL... then a system that goes along those lines.

It's like if you sent me an email last year and now you're modifying today the email I received last year, directly in my inbox or worst, my archive! and without knowing it... Stop... wrong direction here... IMHO.

On the volumetrics, a card is what? about 50K avg? so... 20/Meg, 20000/Gig or 20 Millions cards into 1000 Gigabytes... not an issue with the drives of today. Add "Compression" to this... could go to 40+ Millions cards into 1K Gigabytes. Not bad!

Just thinking.... still.

Sylvain Faust, VE2FET

---

VE2FET Sylvain Faust

Keep in mind that eQSL.CC was originally designed around the capabilities that could be supported by the ADIF 1.0 specification.

More recently ADIF 2.0 specification has been introduced and Dave Morris was a contributor to that effort. Thus ADIF 2.0 does allow some improvements in the system and these are currently in development.

It's not true that you can't change your QSO data once it has been submitted. You can go to your Outbox at any time and change your data. Usually, you would only do this in the case of an error.

It is true that if you put rig and antenna information on your eQSL and later change it that old eQSL's will appear with the new information. It's also true that disk space could be expanded to allow room for storage of every eQSL card for a price. I haven't tried to calculate the price but I suspect it would be fairly significant for a site that operates on donations from roughly 6% of its membership. Only Dave Morris can really evaluate that and decide if it is a financial possibility. More difficult to decide is whether or not it's worth the price. I don't personally pay much attention to rig information on QSL cards and wonder how many people do.

What is important to me is the station location and an attractive graphic that I would like to print and hang on the wall. If you change your old not so attractive graphic to a nicer one I would probably like your new card better and the old card would be of no interest no matter what rig information is on it.

---

73, Rich - W3ZJ

Sylvain:
I agree that once an eQSL is sent it should be non-reviseable. Certainly, if the composite eQSL graphic card is downloaded for local printing, that is to say, retrieved, revisions after the fact are non-effective.
I think, however, a composite graphic eQSL card requires closer to 550 kilobytes.

73, de ~ Vince ~
on IOTA NA-026

---

WA2RSX 73 de OPR: VINCE

Hi Vince,

I do save locally all QSL I receive. Try it. They are all below 50K bytes JPG except for some between 50K and 100K, about one over each 10. That's the quality cards you get here.

73, Sylvain, VE2FET

---

VE2FET Sylvain Faust

Yes the cards are not that large Vince. Allot of it depends on the complexity of the graphic and the amount of JPG compression used. But if users follow the instructions and create 528 X 336 pixel graphic at 96 pixels per inch so it will print 5.5 X 3.5 inches they are on average around 50K or so. It occurs to me now that Dave could probably allow users to upload multiple graphics and create a database table containing the name of the graphic and an effective date. Then select the appropriate graphic for the composite card based on the QSO date. This would require some additional disk space but not nearly what it would take to store the composite graphic for every QSL in the system.

---

73, Rich - W3ZJ

A little piece of info that I just learned from Dave today while discussing another topic.

Currently the entire 65.1 million QSO database requires approximatly 30 GB of storage. A llittle rough math on that reveasls that each QSO requires approximately 461 bytes of storage, give or take a few. Thus, to add a 50K qsl image to each qso would increase the amount of storage space required by 108 times. And, that's just the basic storage. You have to back it up both on and off site. Perhaps that provides a little better perspective on this.

---

73, Rich - W3ZJ

Thanks for the info Rich,

The first part of your calculations are correct... the average QSO requires 461 bytes of storage. But you can't simply add 50-Kb to each QSO and multiply this out to an astronomical figure. That isn't the right perspective!

To project storage requirements you need more information. For example; what percentage of existing users have already stored a graphic and what percentage of users would bother to store more than one graphic if the feature was offered.

If the entire existing 30-Gb database was consumed by 50-Kb graphic files, it would hold 600,000 images. That's about six times the number of existing users. From the aveage 461 bytes of data per QSO information you calculated, I can only speculate the percentage of graphic users is very very low.

In any event, Dave is the person who really needs to evaluate the statistics and determine what impact this feature would have on storage requirements. That said, I estimate if 20,000 users stored a second 50-Kb image, it would consume 1-Gb of storage.

Considering current storage costs, Dave might find it to be cost effective or not. The costs associated with mirrored storage in a data center environment are significant compared to you and me runing down to the "Computer Emporium" and buying a 300-Gb drive for $89.

73 de Bob - K0RC

---

73 de Bob - K0RC