There's the issue of data aging. I do not beleive that holding QSL cards ever is the way to go, neither is a requirements. I do think that we proper requirements were to be done that many issues would resolved by themself. Then, some "way of using the system" rules could kick in. For example, (we need stats on this) but, if after an eQSL card is "seen" by the receipient, the user would have the card only for 30 or 60 days before it (the card, not the QSO record) gets destroyed. Meaning, hey, we provided you with the QSL card, now you have to download it and do what ever you want with it, or have us print and mail, etc... I think you get where i'm going.

Proper evaluation of the capacity requirements added to the % of not retreived QSL (which, badly I'm assuming very high since about 90% of my QSO and eQSL cards are done to Ham which are "not" on this system... so, holding SQL ad vitam aeternam?? That too is what I think the core of the problem... that we need to think around. Am I assuming right?

Sylvain, VE2FET

---

VE2FET Sylvain Faust

Sylvain,

Whether a user retrieves a QSL or not is irrelavent to storage requirements. Vince, WA2RSX, wrote an excellent overview of the system design earlier in this thread.

The thing to remember is one grahic background takes up 50-Kb of space whether 1 user or 10,000 users retrieve my card. If I delete that graphic because user #1 has retreived it, the other 9,999 users would not get a background image on my card. The single "master" image would be gone.

The final slide here http://www.eqsl.cc/qslcard/Presentation.cfm?Slide=Step8 shows how the single master image is married to the QSO data "on the fly" and is sent to your computer when you ask to view and/or print a card. The N5UP image in the lower left corner is stored on the system only once. Again, if it is deleted, it won't print on any future card requests.

Addressing your second paragraph, no, whether cards are retrieved or not has no impact on the storage requirements either. An electronic card "not retrieved" is not taking up space like cards sitting in a physical QSL bureau. Slide number 6 of the slide show can be a little misleading. It uses file cabinets to convey a concept, which to most people would interpret as a transfer of something physical. Slide 8 is the best representation of how the eQSL retrieval and printing works.

---

73 de Bob - K0RC

Yes... got all that. Here we're talking about the "next/future" system. The way you explain it, the current system, does not address the current requirements from my point of view... and is the reason we are posting in this thread.

Like I've posted again a week or 2 ago. This way of having live data linked back to pass transactions is very dangerous and not representative of the reality on the way we manage QSL cards. Again, my opinion. I'm not thinking on "how to use this sytem and bending around it", I'm here to think of the requirements for what the system should really be, then see how/what could be done to get there, from what is already there? I'm not there. Diffrent hat...

Sylvain Faust, VE2FET

---

VE2FET Sylvain Faust

Hey Bob,

How did you know that I am using one of thos 300GB $89.00 USB hard drives? In fact I use two of them attached to differnt machinces on my network and store redundant backups on both because I don's trust them as far as I can throw them :-)

The drives on the eQSL server are RAIDS and even those are backed up.

---

73, Rich - W3ZJ

You got TWO of them there 89-buck 300 giggers???

Man, you're living in luxury!!!

---

73 de Bob - K0RC